Mechanisms for dynamic authorization

Abstract

Example embodiments of the present disclosure relate to dynamic authorization. According to an embodiment of the present disclosure, a technical solution for dynamic access control to data is proposed. When receiving a data registration from a data source, the first device checks the type of data to be produced by the data source and adds a policy to the data or updates the existing policy for the data according to its nature. It also serves as an access control decision point to determine the access rights of consumers based on centrally managed policies. Authorization for data access is granted / denied based on local traits / policies. In this way, it implements dynamic, context-aware, and risk-intelligent access control to different types of data from various data sources (i.e., service producers).

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of telecommunications, and more particularly, to a method, device, apparatus, and computer-readable storage medium for dynamic authorization. Background Art

[0002] In recent communication networks, several new technologies have been proposed. For example, a fifth generation (5G) system architecture based on a service-based architecture has been proposed. System functions in the system architecture are implemented through a set of network functions (NFs) that provide services to other authorized NFs to access their services. NF services are a type of capability exposed by NF service producers to other authorized NF service consumers through service-based interfaces. NF services can support one or more NF service operations. For security purposes, service consumers need to be authorized to access services / data. Summary of the invention

[0003] In general, example embodiments of the present disclosure provide a solution for dynamic authorization.

[0004] In a first aspect, a first device is provided. The first device includes at least one processor; and at least one memory, including computer program code; the at least one memory and the computer program code are configured to, together with the at least one processor, enable the first device to receive an authorization request from a second device or a third device, the authorization request being used to authorize a fourth device to access at least one of the following: a data service or data provided by a third device, the authorization request at least indicating an identification of the fourth device. The first device is also enabled to: obtain a profile of the fourth device based on the identification of the fourth device. The first device is also enabled to: determine authorization information of the fourth device based on the profile of the fourth device and the authorization policy of the data or data service. The first device is also enabled to send authorization information of the fourth device generated based on the determination to the second device or the third device.

[0005] In a second aspect, a second device is provided. The second device includes at least one processor; and at least one memory, including computer program code; the at least one memory and the computer program code are configured to, together with the at least one processor, cause the second device to receive a token request for accessing a data service from a fourth device. The second device is also caused to: send an authorization request to the first device, the authorization request is used to authorize the fourth device to access the data service, and the authorization request at least indicates an identification of the fourth device. The second device is also caused to: receive authorization information of the fourth device from the first device. The second device is also caused to send a response to the token request to the fourth device.

[0006] In a third aspect, a third device is provided. The third device includes at least one processor; and at least one memory, including computer program code; the at least one memory and the computer program code are configured to, together with the at least one processor, cause the third device to receive a service request from a fourth device, the service request including a token for accessing at least one of the following: a data service or data provided by the third device. The third device is also caused to: send an authorization request to the first device, the authorization request being used to authorize the fourth device to access the data service or data, the authorization request at least indicating an identification of the fourth device. The third device is also caused to: receive authorization information of the fourth device from the first device. The third device is also caused to send a service response generated based on the authorization information to the fourth device.

[0007] In a fourth aspect, a method is provided. The method includes receiving an authorization request at a first device and from a second device or a third device, the authorization request being used to authorize a fourth device to access at least one of the following: a data service or data provided by a third device, the authorization request at least indicating an identification of the fourth device. The method also includes obtaining a profile of the fourth device based on the identification of the fourth device. The method also includes determining authorization information of the fourth device based on the profile of the fourth device and an authorization policy for the data service or data. The method further includes sending authorization information of the fourth device generated based on the determination to the second device or the third device.

[0008] In a fifth aspect, a method is provided. The method includes receiving, at a second device and from a fourth device, a token request for accessing a data service. The method also includes sending an authorization request to a first device, the authorization request being used to authorize the fourth device to access the data service, the authorization request indicating at least an identification of the fourth device. The method also includes receiving authorization information of the fourth device from the first device. The method further includes sending a response to the token request to the fourth device.

[0009] In a sixth aspect, a method is provided. The method includes receiving a service request at a third device and from a fourth device, the service request including a token for accessing at least one of the following: a data service or data provided by the third device. The method also includes sending an authorization request to a first device, the authorization request being used to authorize the fourth device to access the data service or data, the authorization request at least indicating an identification of the fourth device. The method also includes receiving authorization information of the fourth device from the first device. The method further includes sending a service response generated based on the authorization information to the fourth device.

[0010] In a seventh aspect, an apparatus is provided. The apparatus includes a component for receiving, at a first device and from a second device or a third device, an authorization request for authorizing a fourth device to access at least one of: a data service or data provided by the third device, the authorization request at least indicating an identification of the fourth device; a component for obtaining a profile of the fourth device based on the identification of the fourth device; a component for determining authorization information of the fourth device based on the profile of the fourth device and an authorization policy of the data service or data; and a component for sending authorization information of the fourth device generated based on the determination to the second device or the third device.

[0011] In an eighth aspect, an apparatus is provided. The apparatus includes a component for receiving, at a second device and from a fourth device, a token request for accessing a data service; a component for sending an authorization request to a first device, the authorization request being used to authorize the fourth device to access the data service, the authorization request indicating at least an identification of the fourth device; a component for receiving authorization information of the fourth device from the first device; and a component for sending a response to the token request to the fourth device.

[0012] In a ninth aspect, an apparatus is provided. The apparatus includes a component for receiving, at a third device and from a fourth device, a service request including a token for accessing at least one of: a data service or data provided by the third device; a component for sending an authorization request to a first device, the authorization request for authorizing the fourth device to access the data service or data, the authorization request indicating at least an identification of the fourth device; a component for receiving authorization information of the fourth device from the first device; and a component for sending a service response generated based on the authorization information to the fourth device.

[0013] In a tenth aspect, a computer-readable medium is provided, wherein the computer-readable medium includes program instructions, and the program instructions are used to cause an apparatus to at least execute the method according to any one of the fourth, fifth or sixth aspects above.

[0014] It should be understood that the invention summary is not intended to identify the key or essential features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Some example embodiments will now be described with reference to the accompanying drawings, in which:

[0016] Figure 1 A reference architecture for network data analysis functions according to conventional techniques is shown;

[0017] Figure 2 A data management framework according to conventional techniques is shown;

[0018] Figure 3 An example communication environment is shown in which example embodiments of the present disclosure may be implemented;

[0019] Figure 4 A signaling flow for determining a preliminary authorization policy according to some example embodiments of the present disclosure is shown;

[0020] Figure 5 shows a signaling flow for obtaining an access token according to some example embodiments of the present disclosure;

[0021] Figure 6 shows a signaling flow for controlling access to data according to some example embodiments of the present disclosure;

[0022] Figure 7 A flowchart showing a method implemented at a first device according to some example embodiments of the present disclosure is shown;

[0023] Figure 8 A flowchart showing a method implemented at a second device according to some other example embodiments of the present disclosure is shown;

[0024] Fig. 9 A flowchart showing a method implemented at a third device according to some other example embodiments of the present disclosure is shown;

[0025] Fig.10 shows a simplified block diagram of an apparatus suitable for implementing an example embodiment of the present disclosure; and

[0026] Fig.11 A block diagram of an example computer-readable medium is shown according to some example embodiments of the present disclosure.

[0027] Throughout the drawings, the same or similar reference numerals refer to the same or similar elements. DETAILED DESCRIPTION

[0028] The principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described only for illustrative purposes and to help those skilled in the art understand and implement the present disclosure, rather than to impose any limitation on the scope of the present disclosure. The embodiments described herein can be implemented in various ways different from the ways described below.

[0029] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

[0030] References in this disclosure to "one embodiment," "an embodiment," "an exemplary embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0031] It should be understood that although the terms "first" and "second" etc. can be used to describe various elements in this article, these elements should not be limited to these terms. These terms are only used to distinguish one element from another element. For example, without departing from the scope of the example embodiments, the first element can be referred to as the second element, and similarly, the second element can be referred to as the first element. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0032] The terms used herein are for the purpose of describing specific embodiments only and are not intended to limit the example embodiments. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the terms "comprises", "comprising", "has", "having", "includes", and / or "including", when used herein, specify stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0033] As used in this application, the term "circuitry" may refer to one or more or all of the following:

[0034] (a) pure hardware circuit implementation (such as implementation in analog and / or digital circuitry only) and

[0035] (b) a combination of hardware circuitry and software such as (where applicable):

[0036] (i) a combination of analog and / or digital hardware circuits and software / firmware, and

[0037] (ii) any portion of hardware processor(s) with software (including digital signal processor(s), software and memory(s) that work together to enable a device (such as a mobile phone or server) to perform various functions and

[0038] (c) Hardware circuits and / or processor(s), such as microprocessor(s) or portions of microprocessor(s), that require software (e.g., firmware) in order to operate, but the software may not be present when the software is not required for operation.

[0039] This definition of circuitry applies to all uses of the 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 only a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. For example, if applicable to a particular claim element, the term circuitry also covers a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in a server, cellular network device, or other computing or network device.

[0040] As used herein, the term "communication network" refers to a network that complies with any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. Further, the communication between the terminal device and the network device in the communication network can be performed according to any suitable generation of communication protocols, including but not limited to the first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, future fifth generation (5G) communication protocols, and / or any other currently known or future developed protocols. The embodiments of the present disclosure can be applied to various communication systems. In view of the rapid development in communication, there will certainly be communication technologies and systems of future types that can embody the present disclosure. It should not be regarded as limiting the scope of the present disclosure to the above-mentioned systems.

[0041] As used herein, the term "network device" refers to a node in a communication network, via which a terminal device accesses the network and receives services from it. A network device may refer to a base station (BS) or an access point (AP), such as a NodeB (NodeB or NB), an evolved NodeB (eNodeB or eNB), a NR NB (also known as a gNB), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, an integrated and access backhaul (IAB) node, a low power node (such as a femto, a pico), a non-terrestrial network (NTN) or a non-terrestrial network device (such as a satellite network device, a low earth orbit (LEO) satellite, and a geosynchronous earth orbit (GEO) satellite), an aircraft network device, etc., depending on the terminology and technology of the application.

[0042] The term "terminal device" refers to any terminal device capable of wireless communication. As an example and not limitation, a terminal device may also be referred to as a communication device, a user equipment (UE), a subscriber station (SS), a portable subscriber station, a mobile station (MS), or an access terminal (AT). The terminal device may include, but is not limited to, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet computer, a wearable terminal device, a personal digital assistant (PDA), a portable computer, a desktop computer, an image capture terminal device (such as a digital camera), a game terminal device, a music storage and playback device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop embedded device (LEE), a laptop mounted device (LME), a USB dongle, a smart device, a wireless client device (CPE), an Internet of Things (IoT) device, a watch or other wearable device, a head mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated processing chain), consumer electronic devices, equipment operating on a commercial and / or industrial wireless network, etc. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

[0043] As mentioned above, service-based architectures have been proposed. Figure 1 1 shows a reference architecture 100 for a network data analysis function (NWDAF) according to conventional techniques. Figure 1As shown, the Nnwdaf_EventsSubscription service and the NWDAF_AnalyticsInfo_Request service are part of the Nnwdaf service-based interface exposed by the Network Data Analysis Function (NWDAF) 110. Known consumers of the Nnwdaf_EventsSubscription service and the NWDAF_AnalyticsInfo_Request service may be: (1) a Policy Control Function (PCF) entity 120, which supports incorporating input from the NWDAF into the allocation policy and traffic control policy for network resources, supports (un)subscribing to analytical information for background data delivery from the NWDAF to determine whether the negotiated delivery policy is affected, and supports incorporating analytical information for QoS sustainability from the NWDAF into the QoS policy; (2) a Network Slice Selection Function (NSSF) entity 130, which supports incorporating load level information from the NWDAF into the consideration of slice selection; (3) an Access and Mobility Management Function (AMF) entity 140, which supports incorporating SMF load information from the NWDAF into the consideration of SMF selection; (4) a Session Management Function (SMF) entity 150, which supports incorporating SMF load information from the NWDAF into the consideration of SMF selection; (5) a Session Management Function (SMF) entity 151, which supports incorporating SMF load information from the NWDAF into the consideration of SMF selection; (6) a Session Management Function (SMF) entity 152, which supports incorporating SMF load information from the NWDAF into the consideration of SMF selection; (7) a Session Management Function (SMF) entity 153, which supports incorporating SMF load information from the NWDAF into the consideration of SMF selection; (8) a Session Management Function (SMF) entity 154, which supports incorporating SMF load information from the NWDAF into the consideration of SMF selection; (9) a Session Management Function (SMF) entity 160, which supports incorporating SMF load information from the NWDAF into the consideration of SMF selection; (10) (5) a network exposure function (NEF) entity 160, which supports forwarding UE mobility information from the NWDAF to the AF when untrusted, supports forwarding UE communication information from the NWDAF to the AF when untrusted, and supports forwarding user data congestion information from the NWDAF to the AF when untrusted; (6) an application function (AF) entity 170, which supports receiving UE mobility information from the NWDAF or via the NEF, supports receiving UE communication information from the NWDAF or via the NEF, and supports receiving user data congestion information from the NWDAF or via the NEF; and (7) an operation, administration, and maintenance (OAM) entity 180, which supports receiving observed service experience from the NWDAF.

[0044] The PCF accesses the Nnwdaf_EventsSubscription service at the NWDAF via the N23 reference point. The NSSF accesses the Nnwdaf_EventsSubscription service at the NWDAF via the N34 reference point. The Network Data Analysis Function (NWDAF) service can provide analysis information for different analysis events to the NF consumer. The Network Data Analysis Function (NWDAF) allows the NF consumer to subscribe and unsubscribe to periodic notifications and / or notifications when events are detected.

[0045] NF service is a type of capability exposed by NF as NF service producer to other authorized NF as NF service consumer through service-based interface. NF service can support one or more NF service operations. NF may supply different functions and therefore different NF services. Each NF service supplied by NF should be self-contained, taking actions and management independently of other NF services (e.g., for scaling, repair) supplied by the same NF. Control plane NF within 5G core network can expose its capabilities as services via its service-based interface, which can be reused by control plane core network (CN) NF.

[0046] NF service discovery enables CN NF to discover (multiple) NF instances that provide the expected NF services. Typically, the Network Repository Function (NRF) supports the following functions:

[0047] - Receive NF Discovery Request from the NF instance and provide the information of the discovered (discovered) NF instance to the NF instance;

[0048] - Maintain NF profiles of available NF instances and their supported services.

[0049] In order for NRF to properly maintain information about available NF instances and the services they support, each NF instance informs NRF of the list of NF services it supports. In the new 5G Service-Based Architecture (SBA), once a NF registers its services with NRF, it simply exposes the services that any authorized consumer can consume, without having to define new point-to-point interfaces and procedures between two network functions as needed. This provides greater flexibility and efficiency by decoupling service consumers from service producers.

[0050] Figure 2A data management framework 200 according to conventional technology is shown. The data management framework 200 may include a data consumer 210, a data producer 220, a data collection coordination function (DCFF) entity 230, a consumer adapter 240, a producer adapter 250, and a DCFF adapter 260. It should be noted that the data management framework may include other entities (e.g., data repositories), which are omitted for clarity. The data management framework may automate the process of data collection from different data producers 220 (sources) and distribution between different data consumers 210. The data collection coordination function (DCCF) is a control plane function that coordinates data collection and triggers the delivery of data to consumers. The consumer adapter 240 and the producer adapter 250 may isolate the message bus protocol from the data consumer 210 and the data producer 220. Authorization of consumers of analytical data / information from analytical services is addressed to a limited extent. For example, it raises the need for consumers of authorized data management frameworks, but does not define a solution.

[0051] Future networks will be more heterogeneous, dynamic and scalable, for example, 5G network slices customized for specific services. Access control solutions for analytical services should take into account various data sources and data consumers, and should establish and adapt to the changing trust relationship between data (service) consumers and data (service) producers. The information / data consumers of analytical services can be, for example, management functions, network functions, applications, and other external entities from different management / security domains (e.g., different slices / slice subnets). Data (service) producers can provide different types of data, such as UE data, service experience data, NF data. In addition, data may need to be classified according to its sensitivity to comply with privacy regulations and security policies from data consumers such as organizations. Therefore, the authorization mechanism for data (service) consumers should support fine-grained authorization solutions such as attribute-based access control (ABAC). So far, the authorization process does not include any property or classification of data from different sources (service producers) provided to NFs, applications or other external entities such as NWDAF.

[0052] According to an embodiment of the present disclosure, a solution for dynamic access control of data is proposed. When receiving a data registration from a data source, the first device checks the type of data to be produced by the data source and adds a policy for the data or updates the existing policy for the data according to its nature. It also serves as an access control decision point to determine the access rights of consumers based on centrally managed policies. Authorization for data access is granted / denied based on local characteristics / policies. In this way, it implements dynamic, context-aware, and risk-intelligent access control to different types of data from various data sources (service producers).

[0053] Figure 3 Schematic diagram of a communication system 300 in which embodiments of the present disclosure may be implemented is shown. The communication system 300 as part of a communication network includes a first device 310, a second device 320, a third device 330, and a fourth device 340. It should be understood that Figure 3 The number of devices shown in is given for illustrative purposes and does not imply any limitation. In some example embodiments, the first device 310 may be an entity or device that can work as an authorization policy management device. The second device 320 may be an authorization server. For example, the second device may be an entity or device that can work as an NRF. Alternatively, the second device 320 may be an entity or device that can work as a DCCF. The third device 330 may be an entity or device that can work as a service provider. It should be noted that the third device 330 may be any suitable device that can provide services and / or data. The fourth device 340 may be an entity or device that can work as a service consumer. It should be noted that the fourth device 340 may be any suitable device that can consume services and / or data. The service consumer may be an operator or a tenant. Alternatively, the service consumer may be a subscriber. The service consumer may be any suitable network function.

[0054] The communication in the communication system 300 can be implemented according to any appropriate (multiple) communication protocols, including but not limited to cellular communication protocols of the first generation (1G), second generation (2G), third generation (3G), fourth generation (4G) and fifth generation (5G), wireless local area network communication protocols (such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, etc.) and / or any other protocol currently known or to be developed in the future. In addition, the communication can utilize any appropriate wireless communication technology, including but not limited to: code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), frequency division duplexer (FDD), time division duplexer (TDD), multiple input multiple output (MIMO), orthogonal frequency division multiple access (OFDMA) and / or any other technology currently known or to be developed in the future.

[0055] Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Figure 4 , which shows a signaling process 400 for determining a preliminary authorization policy according to an example embodiment of the present disclosure. For the purpose of discussion, reference will be made to Figure 3 The signaling process 400 is described below. The signaling process 400 may involve the first device 310, the second device 320, and the third device 330. It should be noted that the signaling process 400 is only an example and not a limitation.

[0056] In some example embodiments, the third device 330 may send 4010 a registration request to the second device 320 in order to register the third device 330 with the second device 320. In some example embodiments, the third device 330 may be registered as a resource server in the second device. For example, the third device 330 may send a Nnrf_NFManagement_NFRegister request to the second device 320. In some example embodiments, the NF profile configuration data of the third device 320 may include additional scope information. For example, for an NF service consumer (e.g., the fourth device 340), the additional scope information may indicate resources and actions (i.e., service operations) allowed for these resources. These resources may be the type of each NF of the service consumer or the instance ID of each NF of the consumer.

[0057] The second device 320 may send 4020 to the first device 310 an additional registration request for registering with the first device 310. In some example embodiments, the additional registration request may include an identification of the third device 330. Alternatively or additionally, the additional registration request may include an expected service range. The additional registration request may also include an expiration time of the data.

[0058] Alternatively, the third device 330 may directly send a registration request to the first device 310 to register with the first device 310. In some example embodiments, the registration request may include an identification of the third device 330. Alternatively or additionally, the registration request may include an expected service range. The registration request may also include an expiration time of the data.

[0059] The first device 310 may determine 4030 a type of data provided by the third device 330. For example, the data type may be UE mobility. Alternatively or additionally, the data type may be UE communication. The data type may also be NF loading. In other embodiments, the data type may be UE mobility prediction. In an example embodiment, the data type may be a slice key performance indicator (KPI). The data type may also be service data. It should be noted that the above data types are merely examples and the data types may be any suitable type.

[0060] The first device 310 may determine 4040 a nature of the data. For example, the first device 310 may classify the data as an analysis result. In some example embodiments, the nature of the data may be signaling data. Alternatively or additionally, the data may be classified as subscriber data. In other embodiments, the nature of the data may be low latency data. In an example embodiment, the nature of the data may be low priority data. Alternatively, the data may be classified as confidential data. In some example embodiments, the nature of the data may be one of: user sensitive data, public data, commercial data, or commercially sensitive data. It should be noted that the above-mentioned nature of the data is merely an example, and the nature of the data may be any suitable nature.

[0061] The first device 310 may determine 4050 an authorization policy for accessing data. For example, the authorization policy may include security requirements for accessing data or data services. Alternatively or additionally, the authorization policy may include a security state required for accessing data or data services. In other embodiments, the authorization policy may include regional requirements for accessing data. It should be noted that the authorization policy may include any appropriate requirements for accessing data provided by the third device 330. For example, the authorization policy may include security requirements for an operator or tenant. The first device 310 may store 4055 the authorization policy locally. Alternatively, the authorization policy may be stored in a storage device accessible to the first device 310.

[0062] The first device 310 may send 4060 a registration response to the second device 320. The registration response may indicate that the third device 330 has successfully registered with the first device 310. In some example embodiments, the registration response may include an authorization policy. Alternatively, the registration response may be sent directly to the third device 330.

[0063] The second device 320 may store 4070 the NF profile configuration data of the third device 320. In other embodiments, the second device 320 may store the authorization policy.

[0064] The second device 320 may send 4080 a registration response to the third device 330. The registration response may indicate that the third device 330 has successfully registered with the second device 320. In some example embodiments, the registration response may include an authorization policy.

[0065] The first device 310 may remove the authorization policy for the data. For example, the authorization policy may be deleted from the storage device. In some example embodiments, if the third device 330 moves to another authorization server (e.g., a different NRF or DCCF), the first device 310 may delete the authorization policy for the data provided by the third device 330.

[0066] In this way, a new interface has been proposed between the second device 320 and the first device 310. An initial authorization policy may be determined, which helps control access to data provided by the service provider.

[0067] Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Figure 5 , which shows a signaling process 500 for obtaining an access token according to an example embodiment of the present disclosure. For the purpose of discussion, reference will be made to Figure 3 A signaling flow 500 is described. The signaling flow 500 may involve a first device 310, a second device 320, and a fourth device 340.

[0068] The fourth device 340 may send 5010 a token request to the second device 320. By way of example only, the fourth device 340 may request an access token from the second device 320 using an Nnrf_AcessToken_Get request operation. In some example embodiments, the second device 320 and the fourth device 340 may be in the same public land mobile network (PLMN). In some example embodiments, the token request may include an identification of the fourth device 340. Alternatively or additionally, the token request may include a requested scope, such as an expected NF service name. Optionally, the token request may include additional scope information. For example, the additional scope information may include a requested resource and a requested action (i.e., service operation) for the resource. Alternatively or additionally, the additional scope information may include an expected NF producer instance and an NF type of an NF consumer. In an example embodiment, the token request may also include a list of network slice selection assistance information (NSSAI). Alternatively, the token request may include a list of network slice instance (NSI) identifiers (IDs) for the expected NF producer instance. In other embodiments, the token request may include the NF Set ID of the intended NF Service Producer instance.

[0069] The second device 320 may send 5020 an authorization request to the first device 310 to authorize the fourth device 340 to access data provided by the third device 330. The authorization request indicates an identification of the fourth device 340.

[0070] The first device 310 may obtain 5030 a profile of the fourth device 340 based on the identification of the fourth device 340. In some example embodiments, the profile may include the identification of the fourth device 340. Alternatively or additionally, the group identification of the fourth device 340 may be included in the profile. In other embodiments, the profile may include the context of the fourth device 340. In addition, the security status of the fourth device 340 may be included in the profile. In some example embodiments, the profile may include data resources or requested actions. The first device 310 may obtain the profile from the authorization request. Alternatively, the first device 310 may obtain the profile from other devices storing the profile. For example, the profile may be obtained from a list, a security analysis function. It should be noted that the profile may also include other parameters related to the fourth device 340, not limited to the above examples.

[0071] The first device 310 may determine 5040 whether to authorize the fourth device 340 to access the data based on the authorization policy and the profile of the fourth device 340. By way of example only, the first device 310 may determine whether the context of the fourth device 340 meets the security requirements based on the authorization policy. If the context meets the security requirements, the fourth device 340 may be authorized to access the data. In some example embodiments, the first device 310 may update the authorization policy based on at least one of the profile of the fourth device 340 or the new requirements from the third device 330. Table 1 below shows an example of data access control. It should be noted that the examples in Table 1 are for illustration only and not limitation.

[0072] Table 1

[0073]

[0074]

[0075] In some example embodiments, the default decision may be a rejection. In some example embodiments, if the fourth device 340 may request data service "D3" and the profile indicates that the context of the fourth device 340 is HPLMN, the decision is "allow". In other words, the first device 310 may authorize the fourth device 340 to access the data. Alternatively, if the fourth device 340 may request data service "D4" and the profile indicates that the context of the fourth device 340 is HPLMN-unsecured, the decision is "reject". In other words, the first device 310 may not authorize the fourth device 340 to access the data.

[0076] The first device 310 may send 5050 authorization information generated based on the determination (5040) to the second device 320. For example, the authorization information may indicate that the fourth device 340 is denied access to the data. Alternatively, the authorization information may indicate that the fourth device 340 is allowed to access the data. In other embodiments, the authorization information may include an updated authorization policy or an initial authorization policy. It should be noted that the authorization information may include any suitable parameters not limited to the above examples.

[0077] The second device 320 may generate 5060 an access token. In some example embodiments, the access token may include one or more of the following: NF instance ID of the second device 120, NF instance ID of the third device 130, NF type of the third device 130, desired service name, scope, expiration time. In addition, the access token may also include allowed resources and allowed actions on the resources (i.e., service operations). In an example embodiment, the access token may also include a list of NSSAIs. Alternatively, the access token may include a list of NSI IDs for the intended NF producer instances. In other embodiments, the access token may include the NF set ID of the intended NF service producer instance. It should be noted that the access token may include any suitable parameters, not limited to the above examples.

[0078] The second device 320 may send 5070 a token response to the fourth device 340. For example, the second device 320 may send an access token to the fourth device 340 in an Nnrf_AccessToken_Get response. If the fourth device 340 is authorized, the token response may include the generated token. If the fourth device 340 is rejected, the second device 320 may send a token response indicating an error response. It should be noted that the access token may be sent in any suitable signaling.

[0079] In some example embodiments, the fourth device 340 can use the access token immediately. Alternatively, the access token can be used later. For example, the fourth device 340 can store the access token and the access token can be reused during the validity period of the access token. In this way, access to data can be adjusted based on the latest conditions of the service consumer, which improves the security of the data.

[0080] Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Figure 6 , which shows a signaling flow 600 for controlling access to data according to an example embodiment of the present disclosure. For the purpose of discussion, reference will be made to Figure 3 A signaling flow 600 is described. The signaling flow 600 may involve a first device 310, a third device 330, and a fourth device 340.

[0081] The fourth device 340 may send 6010 a service request to the third device 330. The service request may include the access token obtained from the second device 320.

[0082] The third device 330 may verify 6020 the access token. For example, the third device 330 may ensure the integrity of the access token by verifying the signature using the NRF public key. Alternatively, the third device 330 may verify the access token by checking the media access control (MAC) value using a shared secret. In other embodiments, the access token may be sent to the first device 310 and the first device 310 may verify the access token.

[0083] The third device 330 may send 6030 an authorization request to the first device 310 to authorize the fourth device 340 to access data provided by the third device 330. The authorization request indicates an identity of the fourth device 340. For example, if the access token is verified, the authorization request may be sent.

[0084] The first device 310 may obtain 6040 a profile of the fourth device 340 based on the identification of the fourth device 340. In some example embodiments, the profile may include the identification of the fourth device 340. Alternatively or additionally, the group identification of the fourth device 340 may be included in the profile. In other embodiments, the profile may include the context of the fourth device 340. In addition, the security status of the fourth device 340 may be included in the profile. In some example embodiments, the profile may include data resources or requested actions. The first device 310 may obtain the current profile from the authorization request. Alternatively, the first device 310 may obtain the current profile from other devices storing the profile. For example, the profile may be obtained from a list, a security analysis function. It should be noted that the profile may also include other parameters related to the fourth device 340, not limited to the above examples.

[0085] The first device 310 may determine 6050 whether to authorize the fourth device 340 to access the data based on the authorization policy and the current profile of the fourth device 340. By way of example only, the first device 310 may determine whether the context of the fourth device 340 meets the security requirements based on the authorization policy. If the context meets the security requirements, the fourth device 340 may be authorized to access the data. In some example embodiments, the first device 310 may update the authorization policy based on the current profile of the fourth device 340 and / or new requirements from the third device 330.

[0086] As an example only, during the process of obtaining an access token, if the fourth device 340 can request data service "D3" and the profile indicates that the context of the fourth device 340 is HPLMN, the decision is "allowed". In other words, the fourth device 340 can obtain an access token from the second device 120. During the validity period of the access token, the fourth device 340 can send a service request using the access token and the access token can be successfully verified. The third device 330 can send an authorization request to the first device 310. The first device 310 can obtain the current or latest profile of the fourth device 340. For example, if the current profile indicates that the context of the fourth device is HPLMN, the first device 310 can determine that the fourth device 340 is authorized to access the data. Alternatively, if the current profile indicates that the context of the fourth device is changed to HPLMN-unsafe, the first device 310 can determine that the fourth device 340 cannot be authorized to access the data, even if the access token has been verified. In this way, access to data can be dynamically controlled. When controlling access to data, any changes in the consumer can be taken into account, thereby improving the security of the data.

[0087] The first device 310 may send 6060 authorization information generated based on the determination (6050) to the third device 330. For example, the authorization information may indicate that the fourth device 340 is denied access to the data. Alternatively, the authorization information may indicate that the fourth device 340 is allowed to access the data. In other embodiments, the authorization information may include an updated authorization policy or an initial authorization policy. It should be noted that the authorization information may include any suitable parameters not limited to the above examples.

[0088] The third device 330 may send 6070 a service response to the fourth device 340. If the authorization information indicates that the fourth device 340 is allowed, the service response may indicate that access to the data is allowed. Alternatively, if the authorization information indicates that the fourth device 340 is denied, the service response may indicate that access to the data is denied.

[0089] Figure 7 A flow chart of an example method 700 implemented at a first device 310 according to some example embodiments of the present disclosure is shown. For purposes of discussion, the method 700 will be described from the perspective of the first device 310.

[0090] In some example embodiments, the third device 330 may need to register with the first device 310. For example, the first device 310 may directly receive a registration request for the first device 310 for registering with the first device 310. In some example embodiments, the registration request may include an identification of the third device 330. Alternatively or additionally, the registration request may include an expected service range. The registration request may also include an expiration time of the data.

[0091] Alternatively, the first device 310 may receive an additional registration request from the second device 320. In some example embodiments, the additional registration request may include an identification of the third device 330. Alternatively or additionally, the additional registration request may include an expected service range. The additional registration request may also include an expiration time of the data.

[0092] In some example embodiments, the first device 310 may determine the type of data to be provided by the third device 330. For example, the data type may be UE mobility. Alternatively or additionally, the data type may be UE communication. The data type may also be NF loading. In other embodiments, the data type may be UE mobility prediction. In an example embodiment, the data type may be a slice key performance indicator (KPI). The data type may also be service data. It should be noted that the above data types are merely examples and the data types may be any suitable type.

[0093] In some example embodiments, the first device 310 may determine the nature of the data. For example, the first device 310 may classify the data as an analysis result. In some example embodiments, the nature of the data may be signaling data. Alternatively or additionally, the data may be classified as subscriber data. In other embodiments, the nature of the data may be low-latency data. In an example embodiment, the nature of the data may be low priority data. Alternatively, the data may be classified as confidential data. In some example embodiments, the nature of the data may be one of the following: user sensitive data, public data, commercial data, or commercially sensitive data. It should be noted that the nature of the above data is only an example, and the nature of the data may be any suitable nature.

[0094] The first device 310 can determine an authorization policy for accessing data. For example, the authorization policy may include security requirements for accessing data. Alternatively or additionally, the authorization policy may include a security state required for accessing data. In other embodiments, the authorization policy may include regional requirements for accessing data. It should be noted that the authorization policy may include any appropriate requirements for accessing data provided by the third device 330. For example, the authorization policy may include security requirements for an operator or tenant. The first device 310 may store the authorization policy locally. Alternatively, the authorization policy may be stored in a storage device accessible to the first device 310.

[0095] The first device 310 may send a registration response to the second device 320. The registration response may indicate that the third device 330 has successfully registered with the first device 310. In some example embodiments, the registration response may include an authorization policy. Alternatively, the registration response may be sent directly to the third device 330.

[0096] At block 710, the first device 310 receives an authorization request from the second device 320 or the third device 330. The authorization request may be used to authorize the fourth device 340 to access at least one of: a data service or data provided by the third device 330. The authorization request indicates an identity of the fourth device 340.

[0097] In box 720, the first device 310 obtains a profile of the fourth device 340 based on the identification of the fourth device 340. In some example embodiments, the profile may include the identification of the fourth device 340. Alternatively or additionally, the group identification of the fourth device 340 may be included in the profile. In other embodiments, the profile may include the context of the fourth device 340. In addition, the security status of the fourth device 340 may be included in the profile. In some example embodiments, the profile may include data resources or requested actions. The first device 310 may obtain the profile from the authorization request. Alternatively, the first device 310 may obtain the profile from other devices storing the profile. For example, the profile may be obtained from a list, a security analysis function. It should be noted that the profile may also include other parameters related to the fourth device 340, not limited to the above examples.

[0098] In block 730, the first device 310 determines authorization information for the fourth device 340 based on the profile of the fourth device 340 and the authorization policy of the data service of the data. In some example embodiments, if the authorization request is received from the second device 320, the first device 310 may determine one or more types of data related to the data service accessible to the fourth device 340. By way of example only, the second device 320 may send an authorization request for data service A, and data service A may include data type A1, data type A2, data type A3, and data type A4. The first device 310 may determine that the second device 320 may access data type A1 and data type A3. The authorization information may indicate data type A1 and data type A3. It should be noted that the data service may be any suitable data service.

[0099] In some example embodiments, if the authorization request is received from the third device 330, the first device 310 may determine that the authorization information of the fourth device 340 will be authorized to access the data provided by the third device 330. By way of example only, the first device 310 may determine whether the context of the fourth device 340 meets the security requirements based on the authorization policy. If the context meets the security requirements, the fourth device 340 may be authorized to access the data. In some example embodiments, the first device 310 may update the authorization policy based on the profile of the fourth device 340 and / or new requirements from the third device 330.

[0100] In some example embodiments, the default decision may be rejected. In some example embodiments, if the fourth device 340 may request data service "D3" and the profile indicates that the context of the fourth device 340 is HPLMN, the decision is "allow". In other words, the first device 310 may authorize the fourth device 340 to access the data. Alternatively, if the fourth device 340 may request data service "D4" and the profile indicates that the context of the fourth device 340 is HPLMN-unsecured, the decision is "reject". In other words, the first device 310 may not authorize the fourth device 340 to access the data.

[0101] At block 740, the first device 310 sends authorization information generated based on the determination to the second device 320. For example, the authorization information may indicate that the fourth device 340 is denied access to the data. Alternatively, the authorization information may indicate that the fourth device 340 is allowed to access the data. In other embodiments, the authorization information may include an updated authorization policy or an initial authorization policy. It should be noted that the authorization information may include any suitable parameters not limited to the above examples.

[0102] In some example embodiments, the first device 310 may receive a request for access control information for data from the third device 330. The access control information may include an authorization policy. Alternatively or additionally, the access control information may include other parameters for controlling access to the data, such as a context required to access the data. The first device 310 may send the access control information to the third device 330 based on the request.

[0103] In other embodiments, the first device 310 may receive an update request from the third device 330. The update request may be used to update the authorization policy. For example, the third device 330 may send one or more new requirements for accessing data to the first device 310. The first device 310 may update the authorization policy based on the update request and the new requirements.

[0104] In some example embodiments, the first device 310 may remove the authorization policy. For example, the authorization policy may be deleted from a storage device. In some example embodiments, if the third device 330 moves to another authorization server (e.g., a different NRF or DCCF), the first device 310 may delete the authorization policy for data provided by the third device 330. In other example embodiments, the first device 310 may receive a removal request for removing the authorization policy.

[0105] Figure 8 A flow chart of an example method 800 implemented at the second device 320 according to some example embodiments of the present disclosure is shown. For discussion purposes, the method 800 will be described from the perspective of the second device 320. It should be noted that the dashed boxes are optional.

[0106] In some example embodiments, the second device 320 may receive a registration request from the third device 330 in order to register the third device 330 with the second device 320. In some example embodiments, the third device 330 may be registered as a resource server in the second device 320. For example, the second device 320 may receive an Nnrf_NFManagement_NFRegister request from the third device 330. In some example embodiments, the NF profile configuration data of the third device 320 may include additional scope information. For example, for an NF service consumer (e.g., the fourth device 340), the additional scope information may indicate resources and actions (i.e., service operations) allowed for these resources. These resources may be the type of each NF of the service consumer or the instance ID of each NF of the consumer.

[0107] In some example embodiments, the second device 320 may send an additional registration request to the first device 310 for registering the third device 330 with the first device 310. In some example embodiments, the additional registration request may include at least an identification of the third device 330. Alternatively or additionally, the additional registration request may include an expected service range. The additional registration request may also include an expiration time of the data.

[0108] The second device 320 may receive a registration response from the first device 310. The registration response may indicate that the third device 330 has successfully registered with the first device 310. In some example embodiments, the registration response may include an authorization policy. Alternatively, the registration response may be sent directly to the third device 330.

[0109] In some example embodiments, the second device 320 may store NF profile configuration data of the third device 320. In other embodiments, the second device 320 may store an authorization policy. The second device 320 may also send a registration response to the third device 330. The registration response may indicate that the third device 330 has successfully registered with the second device 320. In some example embodiments, the registration response may include an authorization policy.

[0110] In box 810, the second device 320 receives a token request for accessing a data service from the fourth device 340. By way of example only, the fourth device 340 may request an access token from the second device 320 using an Nnrf_AcessToken_Get request operation. In some example embodiments, the second device 320 and the fourth device 340 may be in the same public land mobile network (PLMN). In some example embodiments, the token request may include an identifier of the fourth device 340. Alternatively or additionally, the token request may include a requested scope, such as an expected NF service name. Optionally, the token request may include additional scope information. For example, the additional scope information may include requested resources and requested actions (i.e., service operations) for the resources. Alternatively or additionally, the additional scope information may include NF types of expected NF producer instances and NF consumers. In an example embodiment, the token request may also include a list of network slice selection assistance information (NSSAI). Alternatively, the token request may include a list of network slice instance (NSI) identifiers (IDs) for the expected NF producer instances. In other embodiments, the token request may include the NF Set ID of the intended NF Service Producer instance.

[0111] At block 820, the second device 320 sends an authorization request to the first device 310 to authorize the fourth device 340 to access the data service provided by the third device 330. The authorization request indicates an identity of the fourth device 340.

[0112] At block 830, the second device 320 receives authorization information generated based on the determination (5040) from the first device 310. For example, the authorization information may indicate that the fourth device 340 is denied access to the data. Alternatively, the authorization information may indicate that the fourth device 340 is allowed to access the data. In other embodiments, the authorization information may include an updated authorization policy or an initial authorization policy. It should be noted that the authorization information may include any suitable parameters not limited to the above examples.

[0113] In some example embodiments, the second device 320 may generate an access token. In some example embodiments, the access token may include one or more of the following: the NF instance ID of the second device 120, the NF instance ID of the third device 130, the NF type of the third device 130, the desired service name, scope, expiration time. In addition, the access token may also include allowed resources and allowed actions on the resources (i.e., service operations). In an example embodiment, the access token may also include a list of NSSAIs. Alternatively, the access token may include a list of NSI IDs for the expected NF producer instances. In other embodiments, the access token may include the NF set ID of the expected NF service producer instance. It should be noted that the access token may include any suitable parameters not limited to the above examples.

[0114] At block 840, the second device 320 may send 5070 a token response to the fourth device 340. For example, the second device 320 may send the access token to the fourth device 340 in an Nnrf_AccessToken_Get response. If the fourth device 340 is rejected, the second device 320 may reply to the token request based on an error response. It should be noted that the access token may be sent in any suitable signaling.

[0115] Fig. 9 A flow chart of an example method 900 implemented at a third device 330 according to some example embodiments of the present disclosure is shown. For ease of discussion, the method 900 will be described from the perspective of the third device 330. It should be noted that the dashed boxes are optional.

[0116] At block 910, the third device 330 receives a service request from the fourth device 340. The service request may include a token for accessing at least one of: a data service or data provided by the third device.

[0117] In some example embodiments, the third device 330 may verify the access token. For example, the third device 330 may ensure the integrity of the access token by verifying the signature using the NRF public key. Alternatively, the third device 330 may verify the access token by checking the media access control (MAC) value using a shared key.

[0118] At block 920, the third device 330 sends an authorization request to the first device 310 to authorize the fourth device 340 to access data services or data provided by the third device 330. The authorization request indicates an identity of the fourth device 340. For example, if the access token is verified, the authorization request may be sent.

[0119] At block 930, the third device 330 receives authorization information generated based on the determination from the first device 310. For example, the authorization information may indicate that the fourth device 340 is denied access to the data. Alternatively, the authorization information may indicate that the fourth device 340 is allowed to access the data. In other embodiments, the authorization information may include an updated authorization policy or an initial authorization policy. It should be noted that the authorization information may include any suitable parameters not limited to the above examples.

[0120] At block 940, the third device 330 sends a service response to the fourth device 340. If the authorization information indicates that the fourth device 340 is allowed, the service response may indicate that access to the data is allowed. Alternatively, if the authorization information indicates that the fourth device 340 is denied, the service response may indicate that access to the data is denied.

[0121] In some example embodiments, the third device 330 may send a registration request to the second device 320 in order to register with the second device 320. In some example embodiments, the third device 330 may register as a resource server in the second device. For example, the third device 330 may send an Nnrf_NFManagement_NFRegister request to the second device 320. In some example embodiments, the NF profile configuration data of the third device 320 may include additional scope information. For example, for an NF service consumer (e.g., the fourth device 340), the additional scope information may indicate resources and actions (i.e., service operations) allowed for these resources. These resources may be the type of each NF of the service consumer or the instance ID of each NF of the consumer.

[0122] Alternatively, the third device 330 may directly send a registration request to the first device 310 to register with the first device 310. In some example embodiments, the registration request may include an identification of the third device 330. Alternatively or additionally, the registration request may include an expected service range. The registration request may also include an expiration time of the data.

[0123] In some example embodiments, the third device 330 may send a request for access control information for the data to the first device 310. The third device 330 may receive the access control information from the first device 310. The access control information may include an authorization policy. Alternatively or additionally, the access control information may include other parameters for controlling access to the data, such as a context required to access the data.

[0124] In other embodiments, the third device 330 may send an update request to the first device 310. The update request may be used to update the authorization policy. For example, the third device 330 may send one or more new requirements for accessing data to the first device 310. The first device 310 may update the authorization policy based on the update request and the new requirements. In some example embodiments, the third device 330 may send a removal request to the first device 310, which is used to remove the authorization policy from the first device 310.

[0125] In some example embodiments, a first device (e.g., first device 310) capable of performing any of the methods 700 may include a component for performing the corresponding operation of the method 700. The component may be implemented in any suitable form. For example, the component may be implemented in a circuit system or a software module. The first device may be implemented as the first device 310 or included in the first device 310. In some example embodiments, the component may include at least one processor and at least one memory, the at least one memory including computer program code. The at least one memory and the computer program code are configured to cause the execution of the device together with the at least one processor.

[0126] In some example embodiments, the apparatus includes a component for receiving, at a first device and from a second device or a third device, an authorization request for authorizing a fourth device to access at least one of: a data service or data provided by a third device, the authorization request indicating at least an identification of the fourth device; a component for obtaining a profile of the fourth device based on the identification of the fourth device; a component for determining authorization information of the fourth device based on the profile of the fourth device and an authorization policy for the data service or data; and a component for sending the authorization information to the second device or the third device.

[0127] In some example embodiments, the apparatus further comprises means for updating an authorization policy for the data based on at least one of: a profile of the fourth device or a new requirement from the third device.

[0128] In some example embodiments, the apparatus further comprises at least one of: a component for receiving a request for access control information for data from a third device, the access control information comprising at least an authorization policy; or a component for receiving an update request from a third device, the update request being used to update the authorization policy.

[0129] In some example embodiments, the apparatus further comprises means for removing an authorization policy for the data.

[0130] In some example embodiments, the profile of the fourth device includes at least one of: a group identification of the fourth device, a role of the fourth device, or a context of the fourth device.

[0131] In some exemplary embodiments, the authorization policy includes at least one of: a security requirement for accessing a data service or data, a service type of data, or a required zone for accessing a data service or data.

[0132] In some example embodiments, the authorization request is received from the second device and the means for determining the authorization information includes means for determining at least one type of data related to the data service accessible to the fourth device.

[0133] In some example embodiments, an authorization request is received from a third device and the component for determining authorization information includes: a component for determining authorization information of a fourth device, the authorization information indicating whether the fourth device is to be authorized to access data provided by the third device; or a component for determining, based on an authorization policy, whether the context of the fourth device meets security requirements for accessing data; and a component for determining that the fourth device is authorized to access the data based on determining that the context of the fourth device meets the security requirements.

[0134] In some example embodiments, the apparatus further includes a component for receiving, from a second device or a third device, a registration request for registering a third device with the first device, the registration request including an identifier of the third device; a component for determining a type of data to be provided by the third device; a component for determining a nature of the data based on the type of the data; and a component for determining an authorization policy for the data based on the nature of the data.

[0135] In some example embodiments, the apparatus further comprises means for sending a registration response to the second device or the third device.

[0136] In some example embodiments, the second first device (e.g., second device 320) capable of performing any of the methods 800 may include a component for performing the corresponding operation of the method 800. The component may be implemented in any suitable form. For example, the component may be implemented in a circuit system or a software module. The first device may be implemented as the second device 320 or included in the second device 320. In some example embodiments, the component may include at least one processor and at least one memory, the at least one memory including a computer program code. The at least one memory and the computer program code are configured to cause the execution of the device together with the at least one processor.

[0137] In some example embodiments, the apparatus includes a component for receiving, at a second device and from a fourth device, a token request for accessing a data service; a component for sending an authorization request to a first device, the authorization request being used to authorize the fourth device to access the data service, the authorization request indicating at least an identification of the fourth device; a component for receiving authorization information of the fourth device from the first device; and a component for sending a response to the token request to the fourth device.

[0138] In some example embodiments, the apparatus further comprises a component for receiving a registration request device for registering with the second device from a third device; a component for sending to the first device an additional registration request for registering the third device with the first device; a component for receiving from the first device a response to the additional registration request, the response including an authorization policy for the data; and a component for sending to the third device a registration response to the registration request.

[0139] In some example embodiments, the third first device (e.g., third device 330) capable of performing any of the methods 900 may include a component for performing the corresponding operation of the method 900. The component may be implemented in any suitable form. For example, the component may be implemented in a circuit system or a software module. The first device may be implemented as a second device 320 or included in the second device 320. In some example embodiments, the component may include at least one processor and at least one memory, the at least one memory including a computer program code. The at least one memory and the computer program code are configured to cause the execution of the device together with the at least one processor.

[0140] In some example embodiments, the apparatus includes a component for receiving a service request at a third device and from a fourth device, the service request including a token for accessing at least one of: a data service or data provided by the third device; a component for sending an authorization request to the first device, the authorization request being used to authorize the fourth device to access the data service or data, the authorization request at least indicating an identification of the fourth device; a component for receiving authorization information of the fourth device from the first device; and a component for sending a service response generated based on the authorization information to the fourth device.

[0141] In some example embodiments, the apparatus further comprises means for sending a registration request to the first device or the second device; and means for receiving a response to the registration request from the first device or the second device.

[0142] In some example embodiments, the apparatus further includes at least one of: a component for sending a request for access control information for data to the first device, the access control information including at least an authorization policy; a component for sending an update request to the first device, the update request being used to update the authorization policy; or a component for sending a removal request to the first device, the removal request being used to remove the authorization policy.

[0143] Fig.10 1 is a simplified block diagram of a device 1000 suitable for implementing an example embodiment of the present disclosure. The device 1000 may be provided to implement a communication device, such as Figure 3 The first device 310, the second device 320 or the third device 330 is shown. As shown in the figure, the device 1000 includes one or more processors 1010, one or more memories 1020 coupled to the processor 1010, and one or more communication modules 1040 coupled to the processor 1010.

[0144] The communication module 1040 is used for two-way communication. The communication module 1040 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interface may represent any interface necessary to communicate with other network elements. In some example embodiments, the communication module 540 may include at least one antenna.

[0145] Processor 1010 may be of any type suitable for the local technology network, and may include, as non-limiting examples, one or more of the following: a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Device 1000 may have multiple processors, such as application specific integrated circuit chips that are time slaved to a clock synchronized with a main processor.

[0146] The memory 1020 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 1024, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disk (CD), digital video disk (DVD), optical disk, laser disk, and other magnetic storage and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 1022 and volatile memories that will not persist for the duration of a power outage.

[0147] Computer program 1030 includes computer executable instructions that are executed by associated processor 1010. Program 1030 may be stored in a memory, such as ROM 1024. Processor 1010 may perform any suitable actions and processes by loading program 1030 into RAM 1022.

[0148] The exemplary embodiments of the present disclosure may be implemented by the program 1030 so that the device 1000 may execute the Figures 3 to 9 Any process of the present disclosure discussed. The exemplary embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0149] In some example embodiments, the program 1030 may be tangibly embodied in a computer-readable medium that may be included in the device 1000 (such as in the memory 1020) or other storage device accessible by the device 1000. The device 1000 may load the program 1030 from the computer-readable medium to the RAM 1022 for execution. The computer-readable medium may include any type of tangible non-volatile storage, such as ROM, EPROM, flash memory, hard disk, CD, DVD, and other magnetic storage and / or optical storage. Fig.11 An example of a computer readable medium 1100 in the form of an optical storage disk is shown. The computer readable medium has a program 1030 stored thereon.

[0150] In general, various embodiments of the present disclosure may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure are illustrated and described as block diagrams, flow charts, or using some other graphical representations, it should be understood that, as non-limiting examples, the boxes, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0151] The present disclosure also provides at least one computer program product, tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer executable instructions, such as those included in a program module, which are executed in a device on a target physical or virtual processor to perform the above-referenced Figures 3 to 9 Any method described. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The functions of program modules can be combined or split between program modules as needed in various embodiments. The machine executable instructions of program modules can be executed in local or distributed devices. In distributed devices, program modules may be located in local and remote storage media.

[0152] The program code for executing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device so that the program code enables the functions / operations specified in the flow chart and / or block diagram to be realized when executed by the processor or controller. The program code can be executed entirely on the machine, partially on the machine as an independent software package, partially on the machine and partially on a remote machine, or completely on a remote machine or server.

[0153] In the context of the present disclosure, computer program codes or related data may be carried by any suitable carrier to enable a device, apparatus or processor to perform various processes and operations as described above. Examples of carriers include signals, computer readable media, etc.

[0154] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable medium may include, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared or semiconductor system, device or apparatus, or any suitable combination of the foregoing. More specific examples of computer readable storage media would include an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0155] In addition, although operations are described in a particular order, this should not be construed as requiring that such operations be performed in the particular order or sequence shown, or that all illustrated operations be performed to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be interpreted as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to a particular embodiment. Certain features described in the context of separate embodiments may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments.

[0156] Although the disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A first device for communication, comprising: at least one processor; as well as at least one memory including computer program code; The at least one memory and the computer program code are configured to, together with the at least one processor, cause the first device to: receiving an authorization request from a second device or a third device, the authorization request being used to authorize a fourth device to access at least one of: a data service or data provided by the third device, the authorization request at least indicating an identification of the fourth device; Based on the identifier of the fourth device, obtaining a profile of the fourth device; determining authorization information of the fourth device based on the profile of the fourth device and an authorization policy of the data service or the data; as well as sending the authorization information to the second device or the third device; The first device is an authorization policy management entity, the second device is an authorization server, the third device is a service producer, and the fourth device is a service consumer.

2. The first device according to claim 1, wherein the first device is further configured to: The authorization policy for the data is updated based on at least one of: the profile of the fourth device or a new requirement from the third device.

3. The first device according to claim 1, wherein the first device is further configured to do at least one of the following: receiving a request for access control information of the data from the third device, the access control information including at least the authorization policy; or An update request for updating the authorization policy is received from the third device.

4. The first device according to claim 1, wherein the first device is further configured to: Remove the authorization policy.

5. The first device according to claim 1, wherein the profile of the fourth device comprises at least one of the following: a group identifier of the fourth device, the role of the fourth device, or The context of the fourth device.

6. The first device according to claim 1, wherein the authorization policy comprises at least one of the following: security requirements for accessing the data service or the data, the type of service the data is serving, or The required area for accessing the data service or the data.

7. The first device of claim 1 , wherein the authorization request is received from the second device, and the first device is caused to determine the authorization information by: At least one type of data related to the data service accessible to the fourth device is determined.

8. The first device of claim 1, wherein the authorization request is received from the third device, and wherein the first device is caused to determine the authorization information by: determining the following authorization information of the fourth device, the authorization information indicating whether to authorize the fourth device to access the data provided by the third device; or determining, based on the authorization policy, whether the context of the fourth device satisfies a security requirement for accessing the data; as well as Based on determining that the context of the fourth device satisfies the security requirement, determining that the fourth device is authorized to access the data.

9. The first device according to claim 1, wherein the first device is further caused to: receiving, from the second device or the third device, a registration request for registering the third device with the first device, the registration request including an identifier of the third device; determining a type of the data to be provided by the third device; determining a nature of the data based on the type of the data; as well as The authorization policy for the data is determined based on the property of the data.

10. The first device according to claim 9, wherein the first device is further caused to: A registration response is sent to the second device or the third device.

11. A second device for communication, comprising: at least one processor; as well as at least one memory including computer program code; The at least one memory and the computer program code are configured to, together with the at least one processor, cause the second device to: receiving a token request for access to a data service from a fourth device; Sending an authorization request to the first device, where the authorization request is used to authorize the fourth device to access the data service, and the authorization request at least indicates an identifier of the fourth device; receiving authorization information of the fourth device from the first device; sending a response to the token request to the fourth device; as well as receiving, from a third device, a registration request for registering with the second device; The first device is an authorization policy management entity, the second device is an authorization server, the third device is a service producer, and the fourth device is a service consumer.

12. The second device according to claim 11, wherein the second device is further configured to: sending, to the first device, a further registration request for registering the third device with the first device, the further registration request including at least an identifier of the third device; receiving a response to the further registration request from the first device; as well as A registration response to the registration request is sent to the third device.

13. A third device for communication, comprising: at least one processor; as well as at least one memory including computer program code; The at least one memory and the computer program code are configured to, together with the at least one processor, cause the third device to: receiving a service request from a fourth device, the service request comprising a token for accessing at least one of: a data service or data provided by the third device; Sending an authorization request to the first device, where the authorization request is used to authorize the fourth device to access the data service or the data, and the authorization request at least indicates an identifier of the fourth device; receiving authorization information of the fourth device from the first device; Sending a service response generated based on the authorization information to the fourth device; as well as Sending a registration request to the first device or the second device; The first device is an authorization policy management entity, the second device is an authorization server, the third device is a service producer, and the fourth device is a service consumer.

14. The third device according to claim 13, wherein the third device is further configured to: A response to the registration request is received from the first device or the second device.

15. The third device according to claim 13, wherein the third device is further configured to do at least one of the following: Sending a request for access control information of the data to the first device, the access control information including at least an authorization policy; sending an update request for updating the authorization policy to the first device; or A removal request for removing the authorization policy is sent to the first device.

16. A method for communication, comprising: receiving, at a first device and from a second device or a third device, an authorization request for authorizing a fourth device to access at least one of: a data service or data provided by the third device, the authorization request indicating at least an identification of the fourth device; Based on the identifier of the fourth device, obtaining a profile of the fourth device; determining authorization information of the fourth device based on the profile of the fourth device and an authorization policy of the data service or the data; as well as sending the authorization information to the second device or the third device; The first device is an authorization policy management entity, the second device is an authorization server, the third device is a service producer, and the fourth device is a service consumer.

17. The method according to claim 16, further comprising: The authorization policy for the data is updated based on at least one of: the profile of the fourth device or a new requirement from the third device.

18. The method according to claim 16, further comprising at least one of the following: receiving a request for access control information of the data from the third device, the access control information including at least the authorization policy; or An update request for updating the authorization policy is received from the third device.

19. The method according to claim 16, further comprising: Remove the authorization policy for the data.

20. The method of claim 16, wherein the profile of the fourth device comprises at least one of the following: a group identifier of the fourth device, the role of the fourth device, or The context of the fourth device.

21. The method of claim 16, wherein the authorization policy comprises at least one of the following: security requirements for accessing the data service or the data, the type of service the data is serving, or The required area for accessing the data service or the data.

22. The method of claim 16, wherein the authorization request is received from the second device, and wherein determining the authorization information comprises: At least one type of data related to the data service accessible to the fourth device is determined.

23. The method of claim 16, wherein the authorization request is received from the third device, and wherein determining the authorization information comprises: determining the following authorization information of the fourth device, the authorization information indicating whether to authorize the fourth device to access the data provided by the third device; or determining, based on the authorization policy, whether the context of the fourth device satisfies a security requirement for accessing the data; as well as Based on determining that the context of the fourth device satisfies the security requirement, determining that the fourth device is authorized to access the data.

24. The method of claim 16, further comprising: receiving, from the second device or the third device, a registration request for registering the third device with the first device, the registration request including an identifier of the third device; determining a type of the data to be provided by the third device; determining a nature of the data based on the type of the data; as well as The authorization policy is determined based on the property of the data.

25. The method according to claim 24, further comprising: A registration response is sent to the second device or the third device.

26. A method for communication, comprising: receiving, at the second device and from a fourth device, a token request for accessing a data service; Sending an authorization request to the first device, where the authorization request is used to authorize the fourth device to access the data service, and the authorization request at least indicates an identifier of the fourth device; receiving authorization information of the fourth device from the first device; sending a response to the token request to the fourth device; as well as receiving, from a third device, a registration request for registering with the second device; The first device is an authorization policy management entity, the second device is an authorization server, the third device is a service producer, and the fourth device is a service consumer.

27. The method according to claim 26, further comprising: sending, to the first device, a further registration request for registering the third device with the first device, the further registration request including at least an identifier of the third device; receiving a response to the further registration request from the first device; as well as A registration response to the registration request is sent to the third device.

28. A method for communication, comprising: receiving, at a third device and from a fourth device, a service request, the service request comprising a token for accessing at least one of: a data service or data provided by the third device; Sending an authorization request to the first device, where the authorization request is used to authorize the fourth device to access the data service or the data, and the authorization request at least indicates an identifier of the fourth device; receiving authorization information of the fourth device from the first device; Sending a service response generated based on the authorization information to the fourth device; as well as Sending a registration request to the first device or the second device; The first device is an authorization policy management entity, the second device is an authorization server, the third device is a service producer, and the fourth device is a service consumer.

29. The method according to claim 28, further comprising: A response to the registration request is received from the first device or the second device.

30. The method of claim 28, further comprising at least one of the following: Sending a request for access control information of the data to the first device, the access control information including at least an authorization policy; Sending an update request for updating the authorization policy to the first device; or A removal request for removing the authorization policy is sent to the first device.

31. An apparatus for communication, comprising: Means for performing the method of any one of claims 16 to 25, the method of any one of claims 26 to 27, or the method of any one of claims 28 to 30.

32. A computer readable medium comprising program instructions, which when executed by a processor implement the method according to any one of claims 16 to 25, the method according to any one of claims 26 to 27, or the method according to any one of claims 28 to 30.

Images