Application programming interface (API) frameworks

Abstract

A method includes obtaining group information indicating a group of user terminals (UTs) and authorization criteria associated with at least one resource of at least one UT of the UTs of the group, transmitting a first message to a first UT of the UTs, the first message requesting that a resource owner (RO) associated with the first UT operate as group resource owner (GRO) for the group and indicating the group of UTs and the authorization criteria, and receiving, from the first UT, a second message indicating the first RO will operate as the GRO. The method further transmits, to the first UT, and based on receiving an access request from an application program interface invoker of a UT of the group to access the at least one resource, a third message including information for enabling an authorization decision at the first user UT in view of the authorization criteria.

Description

APPLICATION PROGRAMMING INTERFACE (API) FRAMEWORKSTechnical Field

[0001] Various example embodiments relate generally to application programming interface (API) frameworks.Background

[0002] An application programming interface (API) comprises software that enables two programs, for example applications, services or microservices, to communicate with one another using defined standards and protocols. An API framework may be considered a system that provides multiple APIs that may be invoked by one or more consumers depending on use case. For example, the Third Generation Partnership Project (3GPP) has specified the so-called Common API Framework (CAPIF) including northbound APIs allowing lower-level network resources to be exposed to higher-level consumers.Summary

[0003] According to some aspects, there is provided the subject matter of the independent claims. Some further aspects are defined in the dependent claims. The embodiments that do not fall under the scope of the claims are to be interpreted as examples useful for understanding the disclosure.

[0004] According to a first aspect, there is provided a first apparatus, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus at least to perform operations, the operations comprising: obtaining group information indicating a group of user terminals and authorization criteria associated with at least one resource of at least one user terminal of the user terminals; transmitting a first message to a first user terminal of the user terminals, the first message comprising a request that a first resource owner, RO, associated with the first user terminal operate or act as group resource owner, GRO, for the group, the first message indicating the group of user terminals and the authorization criteria of the group information; receiving from the first user terminal a second message indicating that the first RO associated with the first user terminal will operate as the GRO for the group; and transmitting, to the first user terminal, based on receiving an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource, a third message including information for enabling an authorization decision to be performed at the first user terminal in view of the authorization criteria associated with the at least one resource.

[0005] In some examples, the operations further comprise authenticating the API invoker of the user terminal associated with the access request, wherein the transmitting the third message is further based on the API invoker being authenticated.

[0006] In some examples, the operations further comprise receiving, from the first user terminal, a fourth message indicating either a positive authorization decision associated with the access request or a negative authorization decision associated with the access request, and transmitting, based on the fourth2message indicating the positive authorization decision associated with the access request, a fifth message to the API invoker of the user terminal associated with the access request, the fifth message including an access token for enabling access to the at least one resource.

[0007] In some examples, the group information further indicates the first RO is a candidate GRO for the group, and wherein the transmitting the first message to the first user terminal is based on the group information that indicates the RO is the candidate GRO.

[0008] In some examples, the group information does not indicate the first RO is a candidate GRO for the group, wherein the operations further comprise determining, based on respective properties, or values of respective properties, of the user terminals of the group, that the first RO is a candidate GRO for the group, wherein the transmitting the first message to the first user terminal is based on said determining.

[0009] In some examples, the respective properties include at least one of: type of user terminal; user interface capability of user terminal; energy level of user terminal; or role of user terminal.

[0010] In some examples, the authorization criteria indicates at least one property, or value of at least one property, required to access the at least one resource, and wherein the information for enabling the authorization decision includes at least one property, or value of at least one property, associated with the access request for comparison with the authorization criteria.

[0011] In some examples, the at least one property comprises at least one of: type of user terminal; purpose of access request; or scope of access request.

[0012] In some examples, the first message comprises at least one information element which includes the group information.

[0013] In some examples, the second message comprises at least one information element indicating that the first RO will operate as the GRO for the group and at least one information element indicating a notification endpoint at which the first user terminal will receive the third message.

[0014] In some examples, the first message is transmitted to, and the second message is received from, a resource owner function, ROF, of the first user terminal.

[0015] In some examples, the first apparatus comprises a common API framework, CAPIF, core function, CCF.

[0016] In some examples, the group information is obtained from a CAPIF administrator.

[0017] According to a second aspect, there is provided a method of a first apparatus, comprising: obtaining group information indicating a group of user terminals and authorization criteria associated with at least one resource of at least one user terminal of the user terminals; transmitting a first message to a first user terminal of the user terminals, the first message requesting that a first resource owner, RO, associated with the first user terminal operate or act as group resource owner, GRO, for the group, the first message indicating the group of user terminals and the authorization criteria of the group information; receiving from the first user terminal a second message indicating that the first RO associated with the first user terminal3will operate or act as the GRO for the group; and transmitting, to the first user terminal, based on receiving an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource, a third message including information for enabling an authorization decision to be performed at the first user terminal in view of the authorization criteria associated with the at least one resource.

[0018] In some examples, the second aspect may comprise any feature described in relation to the first aspect.

[0019] According to a third aspect, there is provided a computer program product comprising program instructions which, when the program instructions are executed by a first apparatus, cause the first apparatus to carry out a method of: obtaining group information indicating a group of user terminals and authorization criteria associated with at least one resource of at least one user terminal of the user terminals; transmitting a first message to a first user terminal of the user terminals, the first message requesting that a first resource owner, RO, associated with the first user terminal operate or act as group resource owner, GRO, for the group, the first message indicating the group of user terminals and the authorization criteria of the group information; receiving from the first user terminal a second message indicating that the first RO associated with the first user terminal will operate or act as the GRO for the group; and transmitting, to the first user terminal, based on receiving an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource, a third message including information for enabling an authorization decision to be performed at the first user terminal in view of the authorization criteria associated with the at least one resource.

[0020] In some examples, the third aspect may comprise any feature described in relation to the first aspect.

[0021] According to a fourth aspect, there is provided a computer program product embodied on a non-transitory distribution medium readable by a computer and comprising program instructions which, when the program instructions are executed by a first apparatus, cause the first apparatus to: obtain group information indicating a group of user terminals and authorization criteria associated with at least one resource of at least one user terminal of the user terminals; transmit a first message to a first user terminal of the user terminals, the first message requesting that a first resource owner, RO, associated with the first user terminal operate or act as group resource owner, GRO, for the group, the first message indicating the group of user terminals and the authorization criteria of the group information; receive from the first user terminal a second message indicating that the first RO associated with the first user terminal will operate or act as the GRO for the group; and transmit, to the first user terminal, based on receiving an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource, a third message including information for enabling an authorization decision to be performed at the first user terminal in view of the authorization criteria associated with the at least one resource.4

[0022] In some examples, the fourth aspect may comprise any feature described in relation to the first aspect.

[0023] According to a fifth aspect, there is provided a first apparatus, comprising: means for obtaining group information indicating a group of user terminals and authorization criteria associated with at least one resource of at least one user terminal of the user terminals; means for transmitting a first message to a first user terminal of the user terminals, the first message requesting that a first resource owner, RO, associated with the first user terminal operate or act as group resource owner, GRO, for the group, the first message indicating the group of user terminals and the authorization criteria of the group information; means for receiving from the first user terminal a second message indicating that the first RO associated with the first user terminal will operate or act as the GRO for the group; and means for transmitting, to the first user terminal, based on receiving an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource, a third message including information for enabling an authorization decision to be performed at the first user terminal in view of the authorization criteria associated with the at least one resource.

[0024] In some examples, the fifth aspect may comprise any feature described in relation to the first aspect.

[0025] According to a sixth aspect, there is provided a second apparatus comprising at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the second apparatus at least to perform operations, the operations comprising: receiving a first message from a first apparatus, the first message requesting that a first resource owner, RO, associated with the second apparatus operate or act as group resource owner, GRO, for a group of user terminals, the first message including group information indicating the user terminals of the group and authorization criteria associated with at least one resource of at least one of the user terminals of the group; transmitting, to the first apparatus, a second message indicating that the first RO will operate or act as the GRO for the group; and receiving, from the first apparatus, and based on the first RO operating or acting as the GRO for the group, a third message indicating an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource and including information for enabling an authorization decision to be performed at the second apparatus in view of the authorization criteria associated with the at least one resource.

[0026] In some examples, the operations further comprise determining, in response to receiving the first message, whether the first RO has previously operated or acted as GRO for the group, wherein: if the first RO has previously operated or acted as GRO for the group, the second message is transmitted to the first apparatus based on the first apparatus having previously operated or acted as GRO for the group; or if the first RO has not previously operated or acted as GRO for the group, the second message is transmitted to5the first apparatus based on receiving a confirmation input indicating that the first RO will operate or act as the GRO for the group.

[0027] In some examples, the operations further comprise obtaining the authorization decision, wherein the authorization decision comprises either a positive or negative authorization decision associated with the access request in view of the authorization criteria associated with the at least one resource; and transmit, to the first apparatus, a fourth message indicating the positive or negative authorization decision associated with the access request.

[0028] In some examples, the authorization criteria indicates at least one property or value of at least one property required to access the at least one resource and the information for enabling an authorization decision includes at least one property or value of at least one property associated with the access request for comparison with the authorization criteria.

[0029] In some examples, the at least one property comprises at least one of: type of user terminal; purpose of access request; or scope of access request.

[0030] In some examples, the operations further comprise providing, to a user interface, an indication of a proposed positive or negative authorization decision based on the authorization criteria and the information for enabling the authorization decision, wherein the positive or negative authorization decision is obtained based on receiving confirmation or rejection of the proposed positive or negative authorization decision via the user interface.

[0031] In some examples, the operations further comprise providing, to a user interface, an indication of the authorization criteria and the information for enabling the authorization decision, wherein the positive or negative authorization decision is obtained via the user interface.

[0032] In some examples, the first message comprises at least one information element which includes the group information.

[0033] In some examples, the second message comprises at least one information element indicating that the first RO will operate or act as the GRO for the group and at least one information element indicating a notification endpoint at which the GRO will receive the third message.

[0034] In some examples, the first message is received by, and the second message is transmitted by, a resource owner function, ROF, of the second apparatus.

[0035] In some examples, the second apparatus comprises a user terminal.

[0036] According to a seventh aspect, there is provided a method of a second apparatus, the method comprising: receiving a first message from a first apparatus, the first message requesting that a first resource owner, RO, associated with the second apparatus operate or act as group resource owner, GRO, for a group of user terminals, the first message including group information indicating the user terminals of the group and authorization criteria associated with at least one resource of at least one of the user terminals of the group; transmitting, to the first apparatus, a second message indicating that the first RO will6operate or act as the GRO for the group; and receiving, from the first apparatus, and based on the first RO operating or acting as the GRO for the group, a third message indicating an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource and including information for enabling an authorization decision to be performed at the second apparatus in view of the authorization criteria associated with the at least one resource.

[0037] In some examples, the seventh aspect may comprise any feature described in relation to the sixth aspect.

[0038] According to an eighth aspect, there is provided a computer program product comprising program instructions which, when the program instructions are executed by a second apparatus, cause the second apparatus to carry out a method of: receiving a first message from a first apparatus, the first message requesting that a first resource owner, RO, associated with the second apparatus operate or act as group resource owner, GRO, for a group of user terminals, the first message including group information indicating the user terminals of the group and authorization criteria associated with at least one resource of at least one of the user terminals of the group; transmitting, to the first apparatus, a second message indicating that the first RO will operate or act as the GRO for the group; and receiving, from the first apparatus, and based on the first RO operating or acting as the GRO for the group, a third message indicating an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource and including information for enabling an authorization decision to be performed at the second apparatus in view of the authorization criteria associated with the at least one resource.

[0039] In some examples, the eighth aspect may comprise any feature described in relation to the sixth aspect.

[0040] According to a ninth aspect, there is provided a computer program product embodied on a non-transitory distribution medium readable by a computer and comprising program instructions which, when the program instructions are executed by a second apparatus, cause the second apparatus to: receive a first message from a first apparatus, the first message requesting that a first resource owner, RO, associated with the second apparatus operate or act as group resource owner, GRO, for a group of user terminals, the first message including group information indicating the user terminals of the group and authorization criteria associated with at least one resource of at least one of the user terminals of the group; transmit, to the first apparatus, a second message indicating that the first RO will operate or act as the GRO for the group; and receive, from the first apparatus, and based on the first RO operating or acting as the GRO for the group, a third message indicating an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource and including information for enabling an authorization decision to be performed at the second apparatus in view of the authorization criteria associated with the at least one resource.7

[0041] In some examples, the ninth aspect may comprise any feature described in relation to the sixth aspect.

[0042] According to a tenth aspect, there is provided a second apparatus, comprising: means for receiving a first message from a first apparatus, the first message requesting that a first resource owner, RO, associated with the second apparatus operate or act as group resource owner, GRO, for a group of user terminals, the first message including group information indicating the user terminals of the group and authorization criteria associated with at least one resource of at least one of the user terminals of the group; means for transmitting, to the first apparatus, a second message indicating that the first RO will operate or act as the GRO for the group; and means for receiving, from the first apparatus, and based on the first RO operating or acting as the GRO for the group, a third message indicating an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource and including information for enabling an authorization decision to be performed at the second apparatus in view of the authorization criteria associated with the at least one resource.Drawings

[0043] In the following, example embodiments will be described in greater detail with reference to the embodiments and the accompanying drawings, in which:

[0044] FIG. 1 illustrates an example API framework system;

[0045] FIG. 2 illustrates an architectural model useful for understanding example embodiments;

[0046] FIG. 3 is a flow diagram in accordance with some example embodiments;

[0047] FIG. 4 is a flow diagram in accordance with some example embodiments;

[0048] FIG. 5 is a signal flow diagram in accordance with some example embodiments;

[0049] FIG. 6 illustrates a system in accordance with some example embodiments;

[0050] FIG. 7A and 7B, which is a continuation of FIG 7A, illustrate a signal flow diagram in accordance with some example embodiments;

[0051] FIG. 8 illustrates an example form of a first message in accordance with some example embodiments;

[0052] FIG. 9 illustrates example group information for the first message;

[0053] FIG. 10 illustrates an example form of a second message in accordance with some example embodiments;

[0054] FIG. 11 illustrates an apparatus; and

[0055] FIG. 12 illustrates a non-transitory medium.Detailed Description

[0056] An application programming interface (API) comprises software that enables two programs, for example (but not limited to) applications, services and microservices to communicate with one another8using defined standards and protocols. An API framework may be considered a system (or platform) that enables publishing, discovery and consumption of multiple APIs, which may include third-part APIs, that may be invoked depending on various use cases.

[0057] For example, the Third Generation Partnership Project (3GPP) has specified the so-called Common API Framework (CAPIF) including northbound APIs allowing lower-level network resources to be exposed to higher-level consumers. The CAPIF functional architecture is specified in 3GPP TS 23.222 and includes a CAPIF core function (CCF), API provider domain functions and API invokers. The CAPIF functional architecture is based on a service-oriented architecture (SOA) approach wherein a service provider may publish to the CCF information on one or more APIs (or service APIs) that it offers, and which may therefore be discovered by service users or consumers, for example via their respective user terminals. In this respect, the CCF may operate as a service access controller. So-called API invokers associated with the service users or consumers may request to invoke a particular API based on an authorization procedure.

[0058] The following terms used herein may have the following definitions from 3GPP TS 23.222. A resource may be an object or component of an API on which operations are acted upon. A resource owner (RO) may be a user terminal user or a mobile network operator (MN) subscriber capable of granting access to a protected resource related to an invoked API via a resource owner function (ROF). A ROF may be an entity that enables the authorization for resource access and managing and revoking authorization for resource access. Resource owner-aware northbound API access (RNAA) may comprise an API invocation scenario where an API invoker needs an authorization from the RO. An API invoker may be an entity that invokes CAPIF or service APIs.

[0059] FIG. 1 illustrates an example CAPIF system 100 based on the SOA. The CAPIF system 100 may comprise at least one service producer 110, at least one service consumer 120, and a CCF 130 operating in the role of service access controller. The CCF 130 may be part of a network-side system or platform. The at least one service producer 110 may in an operation 1.1 publish to the CCF 130 information on one or more APIs that one or more service consumers may use, for example to access one or more other resources (e.g., applications) via the one or more APIs. The at least one service consumer 120 may in an operation 1.2 discover the one or more APIs associated with the at least one service producer 110. The at least one service consumer 120 may comprise a software function known as an API invoker. The at least one service consumer 120, or their API invoker, may, based on a requirement to access or use at least one of the one or more APIs of the service producer 110, provide authorization information to the CCF 130 to obtain an access token for subsequently invoking the at least one API of the service producer 110 in an operation 1.3.

[0060] In some example embodiments, the service producer 110 and service consumer 120 may be comprised in respective user terminals. A user terminal in this context may comprise any end user device9that may be capable of wireless communication. By way of example, a user terminal may be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), or a Mobile Station (MS). The user terminal may include a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, USB dongles, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like.

[0061] In some example embodiments, the CCF 130 may comprise a device, module or function of a network which may comprise, by way of example, a communications network, examples of which are given below. Communication with the CCF 130 may be via a network device or network node. The term “network device” or “network node” refers to a node in a communication network via which user terminal(s) may access the network including the CCF and / or which is capable of controlling radio communication and managing radio resources within a cell. The network node or network device may be referred to as a base station (BS), an access point (AP) or an access node. The network device may be, depending on the applied technology, for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, an Integrated Access and Backhaul (I AB) node, a low power node, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, or an aircraft network device.

[0062] Some example embodiments may be implemented in, or as part of, a communication network, such a communication network that implements any of the following radio access technologies (RATs): Worldwide Interoperability for Micro-wave Access (WiMAX), Global System for Mobile communications (GSM, 2G), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunication System (UMTS, 3G) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), Long Term Evolution (LTE), LTE-Advanced, and enhanced LTE (eLTE), 5G (also called NR), or any future RAT such as 6G. Moreover, communication within the communication network may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple-Input Multiple-Output (MIMO), Orthogonal Frequency Division Multiple (OFDM), and / or Discrete Fourier Transform spread OFDM (DFT-s-OFDM).10

[0063] FIG. 2 illustrates an architectural model 200 for CAPIF, supporting Resource Owner Aware Northbound API Access (RNAA) and is useful for understanding at least some of an authorization process. Within a so-called public land mobile network (PLMN) trust domain 202 is provided the CCF 204 which includes an authorization function 206 and CAPIF APIs 208. The authorization function 206 is an entity which issues access tokens to API invokers (see below) after successfully authenticating a resource owner (RO) and obtaining authorization from them. A RO is a user terminal user or mobile network operator (MNO) subscriber capable of granting access to a resource via an API by means of an RO function (ROF) (see below). Also within the PLMN trust domain 202 is an API producer or provider domain 210 which may include an API management function 212, API publishing function 214 and API exposing function 216, as well as one or more service APIs 218. Also within the PLMN trust domain 202 may be a resource owner (RO) function 220, which is the entity which enables authorization for resource access and for managing and revoking authorizations for resource access. Also within the PLMN trust domain 202 may be an (network) API invoker 222, which is an entity which can invoke CAPIF APIs 208 or service APIs 218.Outside of the PLMN trust domain 202 may be an (external) API invoker 224 having the same function of the API invoker 222. The API invoker 224 may be provided on a user terminal. So-called reference points, for example, CAPIF-1 - CAPIF-8, refer to communication points between different parts of the architectural model 200.

[0064] A detailed explanation of each element of the FIG. 2 architectural model 200 is not considered necessary, but it will be appreciated that a RO, via their ROF, may via reference point CAPIF-8 provide authorization for an API invoker to access a resource via an API and manage and / or revoke authorizations. For example, the reference point CAPIF-1 e may be used for the API invoker 224 to discover the service APIs 218, authenticate itself and obtain authorization. Thereafter, the reference point CAPIF-2e may be used by the API invoker 224 to communicate with the service APIs 218, or a selected subset thereof, for accessing resources associated with the RO.

[0065] An API invoker may be deployed in various ways, for example as an application function (AF) on a user terminal or on a network. An API invoker on a user terminal may be limited to accessing via an API only its own resources. However, it has been proposed that an API invoker, on one user terminal, may request access via an API to at least one resource of another user terminal. For example, in a cellular vehicle-to-everything (C-V2X) use case, a vehicle health monitoring application may involve owners, fleet operators and / / or authorized vehicle service providers (associated with at least one user terminal) monitoring the health of one or more host vehicles (other user terminals) and be alerted when maintenance or service is required. This may require access to an API (or service API) for communicating with at least one resource associated with the host vehicles providing, for example, location information and / or other information such as mileage information and / or other sensed or measured parameters. The resource may be a protected resource in the sense that access to its information via the service API requires prior11authorization. The resource may be provided in the network and is updated with data from the host vehicle. Another scenario may comprise one user terminal setting a quality of service (QoS) or quality of experience (QoE) setting for protocol data unit (PDU) sessions of another user terminal. Others use cases are envisaged. In order for one user terminal to access a protected resource of another user terminal, access to, and use of, an appropriate service API of the other user terminal is needed.

[0066] Example embodiments relate to supporting such scenarios in which API invoker(s) of one user terminal (which belong to a user which may also act as a RO, owning its own protected resources) can access resources, e.g., network-hosted resources, associated with another user terminal (or which belong to another RO) via an API, for example, network-hosted service API which requires prior authorization and, if successful, invocation.

[0067] Figure 3 is a flow diagram showing operations 300 that may be performed by one or more example embodiments. The operations 300 may be performed by hardware, software, firmware or a combination thereof. The operations 300 may be performed by one, or respective, means, a means being any suitable means such as one or more processors or controllers in combination with computer-readable instructions provided on one or more memories.

[0068] The operations 300 may, for example, be performed by a first apparatus, which may comprise a service access controller function of a network, for example, the CCF described above.

[0069] A first operation 301 may comprise obtaining group information indicating a group of user terminals and authorization criteria associated with at least one resource of at least one of the user terminals.

[0070] A second operation 302 may comprise transmitting a first message to a first user terminal of the user terminals of the group, the first message requesting that a first resource owner, RO, associated with the first user terminal operate or act as group resource owner, GRO, for the group and indicating the group of user terminals and the authorization criteria of the group information. As part of, in combination with, or separately and prior to the transmitting the first message to the first user terminal of the user terminals, it may be determined which user terminal of the group of user terminal that the first message is to be transmitted. That is; it is determined which terminal of the group is to be the first terminal to which the first message requesting that a first RO associated with the first user terminal operate or act as GRO is to be transmitted.

[0071] A third operation 303 may comprise receiving, from the first user terminal, a second message indicating that the first RO will operate or act as the GRO for the group.

[0072] A fourth operation 304 may comprise transmitting, to the first user terminal, and based on (e.g., in response to) receiving an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource of another user terminal of the group, a third message including information for enabling an authorization decision to be performed at the first user terminal in view of the authorization criteria associated with the at least one resource.12

[0073] The other user terminal of the group may or may not comprise the first user terminal, the point being that the third message is transmitted to the first user terminal on that basis that the first RO (which is associated with the first user terminal) is operating or acting as GRO for the group.

[0074] In some example embodiments, the first apparatus may be provisioned with the group information. For example, the first apparatus may be provisioned by an administrator, e.g., CAPIF administrator, which may be an authorized user with special permissions for CAPIF operations, including the provisioning of the first apparatus. The group information may for example comprise a group identifier (e.g., GroupID #N), respective identifiers of the plurality of user terminals which are members of the group (e.g., UEID #1 -UEID #M), and predefined authorization criteria for enabling an authorization decision to be performed at, or by the first user terminal. The group information may optionally also comprise an identifier of a group RO (GRO), being the RO associated with the first user terminal of the group of user terminals.Advantageously, the first RO operating or acting as GRO becomes responsible for receiving and authorizing subsequent access requests within the group. The first RO operating or acting as GRO therefore assumes responsibility for controlling access to APIs and associated resources; the first user terminal associated with the first RO may be better placed to handle such authorizations given the type and / or other hardware or energy-related properties of said user terminal with respect to other user terminals. In this manner, an authorization decision may be performed at the first user terminal in view of the authorization criteria associated with the at least one resource.

[0075] In some examples, another operation may comprise (prior to the operation 304) authenticating the API invoker of the user terminal associated with the access request, wherein the third message is transmitted based on (e.g., in further response to) said API invoker being authenticated.

[0076] In some examples, another operation may comprise receiving, from the first user terminal, a fourth message indicating either a positive or negative authorization decision associated with the access request, and transmitting, in response to the fourth message indicating a positive authorization decision associated with the access request, a fifth message to the API invoker of the user terminal associated with the access request, the fifth message including an access token for enabling access to the at least one resource.

[0077] In some examples, the (obtained) group information of operation 301 that is obtained therein further indicates the first RO as a candidate GRO for the group, and the first message is transmitted to the first user terminal based on said indication. For example, the first RO may be predetermined as the candidate GRO for the group, possibly because that RO previously operated or acted as GRO for the same or a similar group of user terminals.

[0078] In some examples, the group information may not indicate the first RO as a candidate GRO for the group. For example, the group information may not indicate any RO as candidate GRO for the group, or may indicate a different RO and that different RO earlier rejected the request to operate or act as GRO for the group. In this case, another operation, prior to the operation 302 or as part of either the operation 30113or operation 302, may comprise determining, based on respective properties, or values of respective properties, of (at least some of) the user terminals of the group, that the first RO associated with the first user terminal is a candidate GRO for the group, wherein the first message is transmitted to the first user terminal based on said determining or determination. For example, the respective properties may include at least one of type of user terminal (type being, e.g., a mobile phone, a smart phone, a tablet, a wearable terminal device, a PDA, image capture terminal devices, vehicle-mounted wireless terminal devices, USB dongles, an loT device, or any of the user terminal devices described herein), user interface capability of user terminal, energy level of user terminal, or role of user terminal (e.g., permitted to be RO or not permitted to be RO, functional role in an industrial process, etc). For example, certain types of user terminal may be preferred or acceptable, and hence their associated RO preferred or acceptable for operating or acting as candidate GRO whereas other types of user terminal (e.g., loT devices) may not be acceptable. For example, a user terminal may be required to have a user interface capability for obtaining subsequent authorizations. For example, a user terminal may be required to have at least a threshold energy level remaining in its battery, assuming that such information is available.

[0079] In some examples, the authorization criteria may indicate at least one property, or value of at least one property, required to access the at least one resource and the information for enabling an authorization decision includes at least one property, or value of at least one property, associated with the access request for comparison with the authorization criteria. For example, the at least one property may comprise at least one of: type of user terminal, purpose of access request, or scope of access request. Examples will be described below.

[0080] In some examples, the first message comprises at least one information element which includes the group information. In some examples, the second message comprises at least one information element indicating that the first RO associated with the first user terminal will operate or act as the GRO for the group and at least one information element indicating a notification endpoint at which the first user terminal will receive the third message.

[0081] In some examples, the first message is transmitted to, and the second message is received from, a resource owner function, ROF, of the first user terminal.

[0082] In some examples, the first apparatus is a CCF of communications network.

[0083] Figure 4 is a flow diagram showing operations 400 that may be performed by one or more example embodiments. The operations 400 may be performed by hardware, software, firmware or a combination thereof. The operations 400 may be performed by one, or respective, means, a means being any suitable means such as one or more processors or controllers in combination with computer-readable instructions provided on one or more memories.

[0084] The operations 400 may, for example, be performed by a second apparatus which may comprise a user terminal.14

[0085] A first operation 401 may comprise receiving a first message from a first apparatus, the first message requesting that a first RO associated with the second apparatus operate or act as group resource owner, GRO, for a group of user terminals and including group information indicating the user terminals of the group and authorization criteria associated with at least one resource of at least one of the user terminals of the group.

[0086] A second operation 402 may comprise transmitting, to the first apparatus, a second message indicating that the first RO associated with the second apparatus will operate or act as the GRO for the group.

[0087] A third operation 403 may comprise receiving, from the first apparatus, and based on the first RO associated with the second apparatus operating or acting as the GRO for the group, a third message indicating an access request, from an application program interface, API, invoker of a user terminal of the group, to access the at least one resource of another user terminal of the group, the third message indicating the access request and including information for enabling an authorization decision to be performed at the second apparatus in view of the authorization criteria associated with the at least one resource.

[0088] In some examples, another operation, prior to the operation 402 or as part of the operation 401 or operation 402, may comprise determining, based on (e.g., in response to) receiving the first message, whether the first RO previously operated or acted as GRO for the group, wherein, if the first RO has previously operated or acted as GRO for the group, the second message is transmitted to the first apparatus or, if the first RO has not previously operated or acted as GRO for the group, the second message is transmitted to the first apparatus based on (e.g., in response to) receiving a confirmation input from the second apparatus (user terminal) that the first RO is associated with (e.g., an input of first RO via the second apparatus that confirms an authorization decision for the access request.

[0089] In some examples, another operation, after receiving the third message, may comprise obtaining either a positive or negative authorization decision associated with the access request in view of the authorization criteria associated with the at least one resource, and transmitting, to the first apparatus, a fourth message indicating the positive or negative authorization decision associated with the access request. The positive or negative authorization decision may be obtained automatically by comparing authorization criteria with information provided with the access request, or may be obtained via interaction with the first RO through a user interface.

[0090] In some examples, the authorization criteria may indicate at least one property or value of at least one property required to access the at least one resource and the information for enabling an authorization decision includes at least one property or value of at least one property associated with the access request for comparison with the authorization criteria. In some examples, the at least one property comprises at least one of: type of user terminal, purpose of access request or scope of access request.15

[0091] In some examples, another operation may comprise providing a user interface indicating the authorization criteria and the information for enabling an authorization decision, wherein the positive or negative authorization decision is obtained via the user interface.

[0092] In some examples, the first message comprises at least one information element which includes the group information. In some examples, the second message comprises at least one information element indicating that the first RO will operate or act as the GRO for the group and at least one information element indicating a notification endpoint at which the second apparatus will receive the third message.

[0093] In some examples, the first message is received by, and the second message is transmitted by, a resource owner function, ROF, of the second apparatus.

[0094] In some examples, the first apparatus is a CCF of a communications network and the second apparatus is a user terminal of the group.

[0095] Some example embodiments will now be described in more detail.

[0096] FIG. 5 illustrates operational stages associated with various functional elements of the FIG. 2 CAPIF architecture. The functional elements may include the CCF 204, API exposing function (AEF) 216, RO function 220 and API invoker 224.

[0097] A first operation 5.1 comprises the CCF being provisioned with the group information as per the operations 301 - 303 described above.

[0098] Second to fifth operations 5.2 to 5.5 are same or similar to operations described in 3GPP TS 23.222, clause 8.34.3.

[0099] For example, a second operation 5.2 comprises onboarding of an API invoker 224 to the CAPIF. This operation 5.2 may comprise a one-time onboarding process that enrolls the API invoker 224 as a recognized user of the CAPIF, which may be triggered by the API invoker via reference point CAPIF-1 or CAPI F-1 e or may be based on the provisioning. For example, the API invoker 224 may transmit to the CCF 204 an onboard API invoker request, including onboarding information, APIs being enrolled for and a proposed expiration time. The CCF 204 may respond with an onboard API invoker response including onboarding status (success or failure), enrolled information which may include information to allow the API invoker 224 to be authenticated and to obtain authorization for service APIs, service API information, a reason (if the onboarding status is failure) and an expiration time at which time the CCF 204 may cancel the enrollment.

[0100] For example, a third operation 5.3 comprises authentication between the API invoker 224 and the CCF 204 using the onboarding information described above, further details of which may be found in 3GPP TS 23.222.

[0101] For example, a fourth operation 5.4 comprises the process of the API invoker 224 discovering service APIs, further details of which may be found in 3GPP TS 23.222.16

[0102] For example, a fifth operation 5.5 comprises the API invoker 224 obtaining authorization information to access at least one of the service APIs. This may involve the CCF 204 transmitting, to the API invoker 224, information for enabling an authorization decision to be performed.

[0103] For example, a sixth operation 5.6 comprises service API invocation by the API invoker 224 which is via the API exposing function 216. This assumes a positive authorization of the API invoker 224 or user terminal with which the API invoker is associated.

[0104] FIG. 6 illustrates an example system 600 according to some example embodiments, comprising first to third user terminals (UEs) 601 - 603. The first to third user terminals 601 - 603 may comprise a group 605 of user terminals with Group ID = #N. The first to third user terminals 601 - 603 may have respective identifiers UEID #1 - UEID #3 and are associated with respective first to third ROs 601 A — 601 C. The first to third user terminals 601 - 603 may communicate with a network node 610 using any of the above-described methods and protocols. Network-side components 608 may include a CCF 620 and an AEF 630. The AEF 630 may expose one or more service APIs 640 which may be required to access, for example, other protected resources such as location data, QoS and / or QoE settings for PDU sessions, user data, maintenance or service data, which are given by way of non-limiting example.

[0105] In the illustrated scenario which follows, it will be assumed that the third user terminal 603 wishes to invoke a service API 640 targeting resources owned by another user terminal or RO of the group, which could be the first or second user terminal 601 , 602. The first UE 601 is assumed to include a ROF 650 and the third UE 603 includes an API invoker 660 for invoking CAPIF and / or service APIs.

[0106] FIG. 7A and 7B, which is a continuation of FIG 7A, illustrate a message flow diagram for the FIG. 6 system 600 according to an example embodiment.

[0107] Staring with FIG. 7A, a first operation 7.1 comprises group information provisioning. A CAPIF administrator 660, which may be an authorized user with special permissions for CAPIF operations, may provide a set of group information to the CCF 620.

[0108] The group information may, for example, include the Group ID = #N and indicate the members of the group, e.g., UEID #1 - UEID #3, and possibly their associated first to third ROs 601 A - 601 C.

[0109] The group information may also include authorization criteria or similar which indicates at least one property, or value of at least one property, required to access at least one resource associated with at least one member of the group 605. The at least one resource may be accessed via an API. Example properties may include at least one of type of user terminal, purpose of access request and / or scope of access request. For example, the authorization criteria may include a list of valid / supported user terminal type(s), purpose(s) and / or scope(s) for which a service API call is authorized.

[0110] The group information may optionally also include a GRO identifier.

[0111] In this example, it is assumed that the GRO identifier indicates that the first RO 601 A associated with the first user terminal 601 is the GRO and hence a second operation 7.2 comprises transmitting a17GRO provisioning request to the first user terminal 601. The GRO provisioning request may include all or at least some of the group information.

[0112] Alternatively, if the group information does not include a GRO identifier, the CCF 620 may determine which of the first to third ROs 601 A - 601 C respectively associated with the first to third user terminals 601 - 603 is a candidate GRO for the group 605. The determining may be based on respective properties, or values of respective properties, of the respective user terminals of the group 605. The respective properties may include at least one of: type of user terminal, user interface capability of the user terminal, energy level of the user terminal or role of the user terminal, for example within an application execution context. For example, a RO of a particular user terminal may have been tagged in an application with a role as leader or co-leader of a V2V fleet. For example, a user terminal having a user interface capability (e.g., display screen and user input means) may be a candidate over that or those user terminal that do not have a user interface capability. For example, a user terminal with an above-threshold remaining energy level may be a candidate over that or those user terminal with a below-threshold remaining energy level (i.e., remaining energy below a threshold level or relative to a threshold level). A combination of properties and / or values thereof may be considered, and each user terminal ranked according to the combination considered to identify that which user terminal of the associated first to third ROs 601 A - 601 C is the candidate GRO for the group 605. When a candidate GRO for the group 605 is determined, the GRO provisioning request is transmitted to the candidate RO via their associated user terminal as per the second operation 7.2.

[0113] The GRO provisioning request may be received by the ROF 650 of the first user terminal 601.

[0114] A third operation 7.3 may comprise the first user terminal 601 processing the received provisioning request. For example, if the first RO 601 A or ROF 650 of the first user terminal 601 is not configured to operate or act as GRO for the group 605, the ROF may require user confirmation from the first RO 601 A that they will operate or act as GRO for the group 605. For example, the ROF 650 may output via a user interface a prompt requesting that the first RO 601 A accept or deny / reject the provisioning request. The first RO 601 A may, for example, deny / reject the provisioning request if they are about to take the first user terminal 601 offline. In this case, the CCF 620 may determine an alternative RO as the candidate GRO and repeat the above process in relation to their respective user terminals. If the first RO 601 a accepts the provisioning request and / or if the ROF 650 has previously been configured to operate or act as GRO for the group 605, the ROF may generate / provide notification endpoint information (e.g., a network address) at which it can (subsequently) receive authorization requests in a later stage.

[0115] It is assumed that the first RO 601A via the ROF 650 of the first user terminal 601 accepts the provisioning request. In one embodiment, the ROF 650 is provisioned with (has access to) the authorization information received in the second operation 7.2 potentially avoiding or minimizing further interactions with the first RO of the first user terminal 601 because, some authorization requests can be18automatically rejected on this basis, for example in the case that an access request comes from a user terminal not being part of the group 605 and / or if the requested purpose and / or scope is not one permitted in the authorization information, and so on.

[0116] A fourth operation 7.4 may comprise the ROF 650 of the first user terminal 601 transmitting a GRO provisioning response to the CCF 620. This may indicate either an accept or deny / reject GRO provisioning response. If the GRO provisioning response is acceptance, the GRO provisioning response may include the notification endpoint information for the group 605.

[0117] A fifth operation 7.5 may comprise the situation where the API invoker 660 of the third user terminal 603 transmits a service API request to the CCF 620. The service API request is a request for using a service API 640 to access at least one other resource of, say, the first and / or second ROs 601 A, 601 B. The service API request may include Group ID = #N, the identity of the relevant userterminal(s), say UEID #2, the at least one target resource(s) to be accessed and the purpose(s) (e.g. reason for the which the service wil be used) and / or scope(s) (e.g., timeframe associated with requested service) of the request for the at least one target resource(s), such as for vehicle maintenance monitoring purposes and over specific time period.

[0118] A sixth operation 7.6 may comprise the CCF 620 performing (e.g., conventional) authentication of the API invoker 660 of the third user terminal in accordance with 3GPSS TS 33.122. This operation could be performed quickly (e.g., without additional signalling related to obtained authentication) if authentication information was also provisioned in the first operation 7.1.

[0119] Continuing to FIG. 7B, a seventh operation 7.7. may comprise resolving or determining that the first RO 601 A (or rather their ROF 650 in first user terminal 601) is operating or acting as GRO for the group 605. The seventh operation 7.7 may also comprise the CCF 620 determining if the third user terminal 603 (associated with the API invoker 660 from which the service API request was received) is associated with the group 605. If the third user terminal 603 is not associated with the API invoker 660 from which the service API request was received, then the service API request can be denied at this stage. If the third user terminal 603 is associated with the API invoker 660 from which the service API request was received, then subsequent operations are performed.

[0120] An eighth operation 7.8 may comprise the CCF 620 performing RO authorization with the ROF 650 of the first user terminal 601. This operation involves transmitting an authorization request to the notification endpoint of the first user terminal 601 including information for enabling an authorization decision to be performed at the ROF 650 in view of the authorization criteria associated with the at least one resource. The authorization decision is determined by the ROF 650. The authorization decision may be performed, for example, based on presenting via a user interface a proposed authorization decision determined automatically by the ROF 650 based on the authorization criteria and the information for enabling the authorization decision to be performed, following which the ROF receives an input indicating19the first RO 601 A has selected to accept or deny / reject the proposed authorization decision. Alternatively, the authorization decisioned may be performed manually, for example based on the ROF 650 presenting via a user interface the authorization criteria and the information for enabling the authorization decision to be performed by the first RO 601 A and the ROF receiving an input indicating the accept authorization decision or deny / reject authorization decision. For example, the first RO 601 A may manually select to accept or deny / reject the request and the ROF receives an input indicating that decision. For example, if any of the user terminal type, the purpose and / or role included in the service API request do not meet the earlier provisioned authorization criteria, whether alone or in combination, then the service API request can be automatically or manually denied / rejected and the API invoker 660 cannot access the requested resources. The ROF 650 may transmit an authorization response which includes information indicating the authorization decision to the CCF 620.

[0121] A ninth operation 7.9 (assuming the API service request is accepted by a positive authorization decision) may comprise the CCF 620 transmitting a service API authorization response with access token to the API invoker 660 of the third user terminal 603.

[0122] A tenth operation 7.10 may comprise the API invoker 660 of the third user terminal 603 transmitting a service API invocation message, with the access token, to the AEF 640.

[0123] An eleventh operation 7.11 may comprise the AEF 640 handling the Service API invocation and providing a response to the API invoker 660 of the third user terminal 603, following which access to the service API and requested resources can take place.

[0124] For completeness, FIG. 8 illustrates a example form of the GRO provisioning request of operation 7.1 and including at least a first information element which comprises the group information.

[0125] FIG. 9 illustrates a non-exhaustive list of items that may comprise the group information. As noted above, the group information may include at least one of the following: a group identifier, information identifying user terminals that are members of the group (e.g., a list of user terminal that are members of the group), relevant authentication information for each group member, a user terminal identifier of the group resource owner, group owner information (e.g., application provider or user ), authorization information related to the supported applications, application service provider identifier, application identifier, purpose, or scope.

[0126] FIG. 10 illustrates a form of the GRO provisioning response of operation 7.4 and including at least a first information element which indicates a success or failure of the GRO identification request and, if a success, a second information element which provides the notification endpoint at which the GRO should receive authorization requests.

[0127] Example embodiments provide a method and system by which one RO is provisioned or determined to operate or act as GRO for a group of user terminals; this enables authorization decisions to performed by said GRO on behalf of other members of the group of user terminals. The GRO may be20associated with a user terminal which is better placed, for example in terms of hardware resources, to handle such authorization decisions more efficiently.

[0128] Example Apparatus

[0129] FIG. 11 shows, by way of example, a block diagram of an apparatus 10. The apparatus 10 comprises, for example, at least one processor 12 and at least one memory 14 storing instructions 15 that, when executed by the at least one processor, cause the apparatus 10 at least to perform the method or methods as disclosed herein, and any of the embodiments thereof. In an example, the at least one memory and the instructions (e.g. a computer program code, software), are configured, with the at least one processor, to cause the apparatus 10 to perform the method or methods as disclosed herein, and any of the embodiments thereof.

[0130] A processor 12 may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with example embodiments described herein. As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and / or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a user equipment, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0131] The memory 14 may be implemented using any suitable data storage technology. The memory may comprise a database for storing data. The memory 14 may be at least in part external to apparatus 10 but accessible to apparatus 10.

[0132] The instructions 15 may be comprised in a computer readable medium or a non-transitory computer readable medium. A term non-transitory, as used herein, is a limitation of the medium itself (i.e. tangible, not a signal) as opposed to a limitation on data storage persistency (e.g. random access memory, RAM, vs. read only memory, ROM).21

[0133] For example, the apparatus 11 is a first apparatus, for example CCF, or a second apparatus, such as a user terminal.

[0134] The apparatus 10 may be caused or configured to perform at least the method described in any of FIGs. 3, 4 and 7.

[0135] The apparatus may comprise one or more entities of any of protocol layers, such as a MAC entity, an RRC entity, an RLC entity, a PDCP entity or a PHY entity.

[0136] The apparatus 10 comprises a radio interface 16. The radio interface 16 may provide the apparatus 10 with communication capabilities. The radio interface 16 may comprise a receiver configured to receive information in accordance with at least one cellular or non-cell ular standard. The radio interface 16 may comprise a transmitter configured to transmit information in accordance with at least one cellular or non-cellular standard. The receiver may comprise more than one receiver. The transmitter may comprise more than one transmitter. The radio interface 16 may comprise a transceiver configured to receive and transmit information in accordance with at least one cellular or non-cell ular standard. The transceiver may comprise more than one transceiver.

[0137] The apparatus 10 may comprise a user interface 18 comprising, for example, at least one of a keypad, a microphone, a touch display, a display, a speaker, etc. The user interface 18 may be used to control the apparatus by the user. The user interface 18 may be external to the apparatus 10. For example, the apparatus 10 may be connected to another device, such as a computer, either via wireless or wired connection, and the apparatus 10 is controlled by the user via the computer.

[0138] FIG. 12 shows a non-transitory media 800 according to some embodiments. The non-transitory media 800 is a computer readable storage medium. It may be e.g. a CD, a DVD, a USB stick, a blue ray disk, etc. The non-transitory media 800 stores computer program code, causing an apparatus to perform the method of any preceding process for example as disclosed in relation to the flow diagrams and related features thereof.

[0139] Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and / or protocols and / or methods may be different, as long as they provide a corresponding functionality. For example, embodiments may be deployed in 2G / 3G / 4G / 5G networks and further generations of 3GPP but also in non-3GPP radio networks such as WiFi.

[0140] In an embodiment, at least some of the processes described herein may be carried out by an apparatus comprising means for carrying out at least some of the described processes. Means for performing method steps as disclosed herein may include software and / or hardware components of the apparatus 10. For example, the at least one processor 12, the memory 14, and the computer program code form means for carrying out the method or methods as disclosed herein, and any of the embodiments thereof. As used herein the term “means” is to be construed in singular form, i.e. referring to a single22element, or in plural form, i.e. referring to a combination of single elements. Therefore, terminology “means for [performing A, B, C]”, is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C. Further, terminology “means for performing A, means for performing B, means for performing C” is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C.

[0141] Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.23

Claims

Claims1. A second apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the second apparatus at least to perform operations, the operations comprising:receiving a first message from a first apparatus, the first message requesting that a first resource owner, RO, associated with the second apparatus operate as group resource owner, GRO, for a group of user terminals, the first message including group information indicating the user terminals of the group and authorization criteria associated with at least one resource of at least one of the user terminals of the group;transmitting, to the first apparatus, a second message indicating that the first RO will operate or act as the GRO for the group; andreceiving, from the first apparatus, and based on the first RO operating or acting as the GRO for the group, a third message indicating an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource and including information for enabling an authorization decision to be performed at the second apparatus in view of the authorization criteria associated with the at least one resource.

2. The second apparatus of claim 1 , wherein the operations further comprise:determining, in response to receiving the first message, whether the first RO has previously operated or acted as GRO for the group, wherein:if the first RO has previously operated or acted as GRO for the group, the second message is transmitted to the first apparatus based on the first having previously operated or acted as GRO for the group; orif the first RO has not previously operated as GRO for the group, the second message is transmitted to the first apparatus based on a confirmation input indicating the first RO will operate or act as the GRO for the group.

3. The second apparatus of claim 1 or claim 2, wherein the operations further comprise:obtaining the authorization decision, wherein the authorization decision comprises either a positive or negative authorization decision associated with the access request in view of the authorization criteria associated with the at least one resource; andtransmitting, to the first apparatus, a fourth message indicating the positive or negative authorization decision associated with the access request.

244. The second apparatus of any one of claims 1 to 3, wherein the authorization criteria indicates at least one property or value of at least one property required to access the at least one resource and the information for enabling the authorization decision includes at least one property or value of at least one property associated with the access request for comparison with the authorization criteria.

5. The second apparatus of claim 4, wherein the at least one property comprises at least one of:type of user terminal;purpose of access request; orscope of access request.

6. The second apparatus of any one of claims 1 to 5, wherein the operations further comprise:providing, to a user interface, an indication of a proposed positive or negative authorization decision based on the authorization criteria and the information for enabling the authorization decision, wherein the positive or negative authorization decision is obtained based on receiving confirmation or rejection of the proposed positive or negative authorization decision via the user interface.

7. The second apparatus of any one of claims 1 to 5, wherein the operations further comprise:providing, to a user interface, an indication of the authorization criteria and the information for enabling the authorization decision,wherein the positive or negative authorization decision is obtained via the user interface.

8. The second apparatus of any one of claims 1 to 7, wherein the first message comprises at least one information element which includes the group information.

9. The second apparatus of any one of claims 1 to 8, wherein the second message comprises at least one information element indicating that the first RO will operate as the GRO for the group and at least one information element indicating a notification endpoint at which the GRO will receive the third message.

10. The second apparatus of any one of claims 1 to 9, wherein the first message is received by, and the second message is transmitted by, a resource owner function, ROF, of the second apparatus.

11. The second apparatus of any one of claims 1 to 10, wherein the second apparatus comprises a user terminal.

12. A first apparatus comprising:at least one processor; andat least one memory storing instructions which, when executed by the at least one processor, cause the first apparatus at least to perform operations, the operations comprising:obtaining group information indicating a group of user terminals and authorization criteria associated with at least one resource of at least one user terminal of the user terminals;transmitting a first message to a first user terminal of the user terminals, the first message comprising a request that a first resource owner, RO, associated with the first user terminal operate or act as group resource owner, GRO, for the group, the first message indicating the group of user terminals and the authorization criteria of the group information;receiving from the first user terminal a second message indicating that the first RO associated with the first user terminal will operate as the GRO for the group; andtransmitting, to the first user terminal, based on receiving an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource, a third message including information for enabling an authorization decision to be performed at the first user terminal in view of the authorization criteria associated with the at least one resource.

13. The first apparatus of claim 12, wherein the operations further comprise:authenticating the API invoker of the user terminal associated with the access request, wherein the transmitting the third message is further based on the API invoker being authenticated.

14. The first apparatus of claim 12 or claim 13, wherein the operations further comprise:receiving, from the first user terminal, a fourth message indicating either a positive authorization decision associated with the access request or negative authorization decision associated with the access request, andtransmitting, based on the fourth message indicating the positive authorization decision, a fifth message to the API invoker of the user terminal associated with the access request, the fifth message including an access token for enabling access to the at least one resource.

15. The first apparatus of any one of claims 12 to 14,wherein the group information further indicates the RO is a candidate GRO for the group, and wherein the transmitting the first message to the first user terminal is based on the group information that indicates the RO is the candidate GRO.

16. The first apparatus of any one of claims 12 to 14,wherein the group information does not indicate the RO is a candidate GRO for the group, and wherein the operations further comprise determining, based on respective properties, or values of respective properties, of the user terminals of the group, that the RO is a candidate GRO for the group, wherein the transmitting the first message to the first user terminal based on said determining.

17. The first apparatus of claim 16, wherein the respective properties include at least one of:type of user terminal;user interface capability of user terminal;energy level of user terminal; orrole of user terminal.

18. The first apparatus of any one of claims 12 to 17,wherein the authorization criteria indicates at least one property, or value of at least one property, required to access the at least one resource, andwherein the information for enabling the authorization decision includes at least one property, or value of at least one property, associated with the access request for comparison with the authorization criteria.

19. The first apparatus of claim 18, wherein the at least one property comprises at least one of:type of user terminal;purpose of access request; orscope of access request.

20. The first apparatus of any one of claims 12 to 19, wherein the first message comprises at least one information element which includes the group information.

21. The first apparatus of any one of claims 12 to 20, wherein the second message comprises at least one information element indicating that the RO will operate as the GRO for the group and at least one information element indicating a notification endpoint at which the first user terminal will receive the third message.

22. The first apparatus of any one of claims 12 to 21, wherein the first message is transmitted to, and the second message is received from, a resource owner function, ROF, of the first user terminal.

123. The first apparatus of any one of claims 12 to 22, wherein the first apparatus comprises a common API framework, CAPIF, core function, CCF.

24. The first apparatus of any one of claims 12 to 23, wherein the group information is obtained from a CAPIF administrator.

25. A method of a first apparatus, the method comprising:obtaining group information indicating a group of user terminals and authorization criteria associated with at least one resource of at least one user terminal of the user terminals;transmitting a first message to a first user terminal of the user terminals, the first message comprising a request that a first resource owner, RO, associated with the first user terminal operate as group resource owner, GRO, for the group, the first message indicating the group of user terminals and the authorization criteria of the group information;receiving from the first user terminal a second message indicating that the first RO associate with the first terminal will operate as the GRO for the group; andtransmitting, to the first user terminal, based on receiving an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource, a third message including information for enabling an authorization decision to be performed at the first user terminal in view of the authorization criteria associated with the at least one resource.

26. A method of a second apparatus, the method comprising:receiving a first message from a first apparatus, the first message requesting that a first resource owner, RO, associated with the second apparatus operate or act as group resource owner, GRO, for a group of user terminals and including group information indicating the user terminals of the group and authorization criteria associated with at least one resource of at least one of the user terminals of the group;transmitting, to the first apparatus, a second message indicating that the first RO will operate or act as the GRO for the group; andreceiving, from the first apparatus, and based on the first RO operating or acting as the GRO for the group, a third message indicating an access request from an application program interface, API, invoker of a user terminal of the group to access the at least one resource and including information for enabling an authorization decision to be performed at the second apparatus in view of the authorization criteria associated with the at least one resource.

Images