Method, device and storage medium for setting device access control permissions

Abstract

The application discloses a method and device for setting access control permissions of an equipment, an equipment and a storage medium, and relates to the technical field of Internet of Things. The method comprises the following steps: a first application program sends an open pairing command request to an Internet of Things equipment, wherein the open pairing command request is a request of the first application program for opening a pairing function of the Internet of Things equipment; and the open pairing command request comprises first permission information set by the first application program, and the first permission information is used for setting access control permissions of a second application program to the Internet of Things equipment. According to the application, the permissions of the second application program can be set by the first application program before the second application program establishes pairing with the Internet of Things equipment, the permissions of the second application program are controllable, and the safety is improved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a method, apparatus, device, and storage medium for setting device access control permissions. Background Technology

[0002] With the development of IoT technology, users can access and control IoT devices through apps installed on their terminal devices.

[0003] In related technologies, after a first application (such as APP A) completes pairing with an IoT device and obtains administrator privileges for that device, when a second application (such as APP B, another application different from APP A) performs pairing and configuration on the device, the second application has the same administrator privileges as the first application.

[0004] In this situation, the permissions of the second application that is paired later are uncontrollable, which poses a security risk. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for setting device access control permissions. The technical solution is as follows:

[0006] According to one aspect of the embodiments of this application, a method for setting device access control permissions is provided, the method being executed by an Internet of Things (IoT) device, the method comprising:

[0007] The system receives an open pairing command request from a first application, which is a request from the first application to enable pairing functionality for the IoT device; wherein, the open pairing command request includes first permission information set by the first application, which is used to set access control permissions for the second application for the IoT device.

[0008] According to one aspect of the embodiments of this application, a method for setting device access control permissions is provided, the method being executed by a first application, the method comprising:

[0009] Sending an open pairing command request to an IoT device, wherein the open pairing command request is a request from the first application to the IoT device to enable pairing functionality; wherein the open pairing command request includes first permission information set by the first application, the first permission information being used to set access control permissions for the second application for the IoT device.

[0010] According to one aspect of the embodiments of this application, a method for setting device access control permissions is provided, the method being executed by a second application, the method comprising:

[0011] Receive OT (Onboarding Token) data sharing information from the first application;

[0012] If the OT data sharing information includes first permission information, a request to set ACL (Access Control List) information carrying the first permission information is sent to the IoT device; wherein, the first permission information is set by the first application, and the first permission information is used to set the access control permissions of the second application for the IoT device.

[0013] According to one aspect of the embodiments of this application, a device for setting device access control permissions is provided, the device comprising:

[0014] The request receiving module is used to receive an open pairing command request from a first application, wherein the open pairing command request is a request from the first application to enable the pairing function of the IoT device; wherein the open pairing command request includes first permission information set by the first application, and the first permission information is used to set the access control permissions of the second application for the IoT device.

[0015] According to one aspect of the embodiments of this application, a device for setting device access control permissions is provided, the device comprising:

[0016] The request sending module is used to send an open pairing command request to an IoT device. The open pairing command request is a request from a first application to the IoT device to enable the pairing function. The open pairing command request includes first permission information set by the first application, which is used to set access control permissions for the second application for the IoT device.

[0017] According to one aspect of the embodiments of this application, a device for setting device access control permissions is provided, the device comprising:

[0018] The information receiving module is used to receive OT data sharing information from the first application.

[0019] The configuration request module is used to send an ACL information configuration request carrying the first permission information to the IoT device when the OT data sharing information includes the first permission information; wherein the first permission information is set by the first application and is used to set the access control permissions of the second application for the IoT device.

[0020] According to one aspect of the embodiments of this application, an Internet of Things (IoT) device is provided, the IoT device including a transceiver;

[0021] The transceiver is configured to receive an open pairing command request from a first application, wherein the open pairing command request is a request from the first application to enable pairing functionality for the IoT device; wherein the open pairing command request includes first permission information set by the first application, the first permission information being used to set access control permissions for the IoT device by the second application.

[0022] According to one aspect of the embodiments of this application, a terminal device is provided, the terminal device including a transceiver;

[0023] The transceiver is used to send an open pairing command request to an IoT device. The open pairing command request is a request from the first application to the IoT device to enable pairing functionality. The open pairing command request includes first permission information set by the first application, which is used to set access control permissions for the second application for the IoT device.

[0024] According to one aspect of the embodiments of this application, a terminal device is provided, the terminal device including a transceiver;

[0025] The transceiver is used to receive OT data sharing information from the first application.

[0026] The transceiver is further configured to send an ACL information setting request carrying the first permission information to the IoT device when the OT data sharing information includes the first permission information; wherein the first permission information is set by the first application and is used to set the access control permissions of the second application for the IoT device.

[0027] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, the storage medium storing a computer program, the computer program being executed by a processor to implement the above-described method for setting device access control permissions on the IoT device side, or the above-described method for setting device access control permissions on the first application side, or the above-described method for setting device access control permissions on the second application side.

[0028] According to one aspect of the embodiments of this application, a chip is provided, the chip including programmable logic circuits and / or program instructions, which, when the chip is running, are used to implement the above-mentioned method for setting device access control permissions on the IoT device side, or the above-mentioned method for setting device access control permissions on the first application side, or the above-mentioned method for setting device access control permissions on the second application side.

[0029] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions, the computer instructions being stored in a computer-readable storage medium, and a processor reading from the computer-readable storage medium and executing the computer instructions to implement the above-described method for setting device access control permissions on the IoT device side, or the above-described method for setting device access control permissions on the first application side, or the above-described method for setting device access control permissions on the second application side.

[0030] The technical solution provided in this application can bring the following beneficial effects:

[0031] By including the first permission information set by the first application in the pairing command request sent by the first application to the IoT device, and using this first permission information to set the access control permissions of the second application for the IoT device, the first application can set the permissions of the second application before the second application establishes pairing with the IoT device, thereby achieving controllable permissions for the second application and helping to improve security. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a schematic diagram of the implementation environment of a solution provided in one embodiment of this application;

[0034] Figure 2 This is a flowchart of the device pairing process provided by the relevant technology;

[0035] Figure 3 This is a flowchart of a method for setting device access control permissions according to an embodiment of this application;

[0036] Figure 4This is a flowchart of a method for setting device access control permissions according to another embodiment of this application;

[0037] Figure 5 This is a flowchart of a method for setting device access control permissions according to another embodiment of this application;

[0038] Figure 6 This is a flowchart of a method for setting device access control permissions according to another embodiment of this application;

[0039] Figure 7 This is a block diagram of a device for setting device access control permissions according to an embodiment of this application;

[0040] Figure 8 This is a block diagram of a device for setting device access control permissions according to another embodiment of this application;

[0041] Figure 9 This is a block diagram of a device for setting device access control permissions according to another embodiment of this application;

[0042] Figure 10 This is a schematic diagram of the structure of an Internet of Things (IoT) device provided in one embodiment of this application;

[0043] Figure 11 This is a schematic diagram of the structure of a terminal device provided in one embodiment of this application. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0045] Please refer to Figure 1 This diagram illustrates an implementation environment provided by an embodiment of this application. The implementation environment may include: a first terminal device 10, an IoT device 20, and a second terminal device 30. This implementation environment can be implemented as an Internet system (such as a home / enterprise smart network system). This IoT system may include multiple IoT devices and multiple terminal devices, and the terminal devices are capable of accessing and controlling the IoT devices.

[0046] Terminal devices (including the first terminal device 10 and the second terminal device 30 described above) may include various handheld devices with wireless communication functions (such as mobile phones, tablets, etc.), vehicle-mounted devices, wearable devices, computing devices or other processing devices connected to a wireless modem, as well as various forms of user equipment (UE), mobile station (MS), terminal device, etc. For ease of description, in the embodiments of this application, the devices mentioned above are collectively referred to as terminals.

[0047] The terminal device may install and run an application for access control of the IoT device 20. In one example, the application for access control of the IoT device 20 installed on the first terminal device 10 is referred to as the first application, and the application for access control of the IoT device 20 installed on the second terminal device 30 is referred to as the second application. For simplicity, in some embodiments, the first application is referred to as APP A, and the second application is referred to as APP B.

[0048] Optionally, the first application and the second application mentioned above may belong to the same ecosystem or different ecosystems. In this embodiment, an ecosystem can refer to a platform built on the same or different architectures by application providers, device manufacturers, or operating system providers. The ecosystem (or platform) to which an application belongs provides background services for that application, such as data storage and retrieval, and cross-platform interaction with other ecosystems. Optionally, ecosystems of different manufacturers include, but are not limited to, the ecosystems of different application providers such as Apple, Google, Xiaomi, Huawei, and OPPO, and may also include, but are not limited to, the Android ecosystem, the iOS ecosystem, or ecosystems provided by some native operating systems or customized operating systems. In one example, the first application is provided by a first manufacturer (such as Apple), and the second application is provided by a second manufacturer (such as Google). In this case, the first application and the second application have different providers, and therefore these two applications belong to two different ecosystems. In another example, the first application is an application in a first operating system (such as the iOS operating system), and the second application is an application in a second operating system (such as the Android operating system or an operating system customized based on the Android operating system). Therefore, these two applications belong to two different operating systems and two different ecosystems.

[0049] The Internet of Things (IoT) device 20 can be any smart device with network connectivity. Taking smart home devices as an example, it can be a smart TV, smart speaker, smart air conditioner, smart light, smart door and window, smart curtain, smart socket, etc., and this application does not limit it in this regard.

[0050] The terminal device and the IoT device 20 can communicate via a network, such as Zigbee, BLEmesh (Bluetooth Low Energy), or WiFi (Wireless Fidelity), etc. This application does not limit the specific network used.

[0051] In some application scenarios, the same IoT device 20 can be accessed and controlled by multiple terminal devices (or applications). Taking a home smart network system as an example, a smart light may be accessed and controlled by multiple terminal devices (or applications) corresponding to multiple family members (such as father, mother, children, nanny, etc.).

[0052] In related technologies, after a first application (such as APP A) pairs with an IoT device and obtains administrator privileges for that device, when a second application (such as APP B, a different application from APP A) pairs and configures the same device, the second application has the same administrator privileges as the first application. For example, suppose a mother uses a first terminal device (with the first application, APP A, installed), and her children use a second terminal device (with the second application, APP B, installed). These first and second terminal devices are two different devices (such as two different mobile phones). After the mother pairs APP A with a smart light and obtains administrator privileges for that smart light, when the children use APP B to pair and configure the smart light, APP B has the same administrator privileges as APP A. In this case, APP B has the highest privileges for the smart light, and APP B can modify the privileges of APP A. This presents a problem of uncontrollable privileges for APP B, posing a security risk.

[0053] Below, in conjunction with Figure 2 First, the device pairing process provided by the relevant technologies will be introduced and explained. Figure 2 In this context, APPA represents the first application, APPB represents the second application, and Node represents the IoT device. The first and second applications belong to different ecosystems. The process may include the following steps (201-216):

[0054] Step 201: As the first ecosystem of Node, APP A first generates OT (Onboarding Token, self-registered token) data;

[0055] Step 202: The user of APP A decides whether to start the Node to enter pairing mode (so that the device can be connected to other ecosystem configurations).

[0056] Step 203: APP A sends an open pairing command request to Node, carrying OT data in TLV (Tag-Length-Value).

[0057] Step 204: Node sends a return message to APP A indicating whether the pairing status has been successfully initiated;

[0058] Step 205: The Node publishes DNS-SD data based on the DNS-SD (DNS Service Discovery) data in OT;

[0059] Step 206: APP A shares OT data with APP B via out-of-band method. APP B belongs to the second ecosystem.

[0060] Step 207, APP B performs a DNS-SD data query;

[0061] Step 208: APP B detects the DNS-SD data sent by Node and resolves the IP (Internet Protocol) address and port number;

[0062] Step 209: APP B and Node establish a secure connection based on the PIN (Personal Identification Number) in the OT data;

[0063] Step 210: APP B initiates device authentication for the Node by sending an operational CSR (Certificate Signing Request) to the device. The device authentication process requires verification of the device's built-in PAA (Product Attestation Authority) and CD (Certification Declaration) information. Since the device has been paired and authenticated by APP A, there is fabricobject information generated by APP A.

[0064] Step 211: The Node sends the CSR, CD, and fabric object information to APP B (APP B checks the device's CD and whether the device has been certified by the CHIP (Connected Home over IP Working Group) certification authority under the Zigbee Alliance).

[0065] Step 212, APP B decides whether to create a new fabric ID or use the fabric ID from the fabric object information; where the fabric ID is an identifier assigned to the device by the ecosystem;

[0066] Step 213: APP B sends the CSR information and fabric ID sent by the Node to CA B (APP B's certificate authority);

[0067] Step 214: CA B generates an OC (Operational Credential) based on the CSR data information and returns it to APP B along with the ecosystem's root certificate RC.B.

[0068] Step 215, APP B sets ACL (Access Control List) information for the device. The data includes: OC (including NodeID information, FabricID information, and operation certificate information generated for the device), root certificate RC.B, and the device's default ACL information (where privilege is set to administrator by default, and target_struct can be the default resource information of the device at the factory).

[0069] Step 216: Generate ACL information for APP B on the Node, and remove the OT data from the Node.

[0070] The OT data in TLV format includes the information shown in Table 1 below:

[0071] Table 1

[0072]

[0073] In addition, ALC privileges (ACL permissions) include the following types of permissions as shown in Table 2:

[0074] Table 2

[0075]

[0076]

[0077] The technical solution provided in this application embodiment, as shown in Table 3, adds permission information (such as Privilege and Target_struct) to the OT data, thereby enabling the first application (APP A) to set the permissions of the second application (APP B) before the second application (APP B) is paired with the IoT device, thus achieving controllable permissions for the second application (APP B).

[0078] Table 3

[0079]

[0080] The technical solution of this application will be described in detail below through several embodiments.

[0081] Please refer to Figure 3 The diagram illustrates a flowchart of a method for setting device access control permissions according to an embodiment of this application. This method can be applied to... Figure 1 The proposed solution is implemented in an environment where the method may include the following steps:

[0082] Step 310: The first application sends an open pairing command request to the IoT device. The open pairing command request is a request from the first application to the IoT device to enable the pairing function. The open pairing command request includes first permission information set by the first application, which is used to set the access control permissions of the second application for the IoT device.

[0083] Accordingly, the IoT device receives an open pairing command request from the first application. After receiving the open pairing command request, the IoT device enables the pairing function. After enabling the pairing function, the IoT device can be discovered and paired by other applications, that is, the IoT device enters a state where it can be configured to connect by other applications.

[0084] Unlike related technologies, in this application, the pairing command request includes first permission information set by the first application. This first permission information is used to set the access control permissions of the second application for the IoT device. That is, before the second application establishes pairing with the IoT device, the first application sets the permissions of the second application and sends them to the IoT device, thereby achieving controllable permissions for the second application.

[0085] In one example, the Open Pairing Command Request includes OT data, which includes first-level permission information. For instance, referring to Tables 1 and 3, if the solution provided by the relevant technology is adopted, the OT data included in the Open Pairing Command Request is as shown in Table 1, including Version, VID (Vendor ID), PID (Product Identifier), Discriminator, PIN (Personal Identifier), DNS-SD, and Special Instructions. Using the technical solution of this application, the OT data included in the Open Pairing Command Request can be as shown in Table 3, which, in addition to the above information, also adds Privilege and Target_struct.

[0086] Privilege and Target_struct are both information related to permission settings. In some embodiments, OT data may include Privilege but not Target_struct. In some embodiments, OT data may include Target_struct but not Privilege. In some embodiments, OT data includes both Privilege and Target_struct.

[0087] The following is an explanation of the aforementioned first-level access information.

[0088] In an exemplary embodiment, the first permission information includes a permission level, namely, the Privilege mentioned above. Different permission levels have different permissions. For example, the permission levels include the five permissions listed in Table 2 above. Currently, in practical applications, permission levels can be added, removed, or modified according to actual needs, and this application does not limit this.

[0089] Optionally, the permission level included in the first permission information can be any of the following:

[0090] The first level of access (equivalent to the Administer access in Table 2) grants the user the ability to view and modify the ACL cluster to which the IoT devices belong.

[0091] The second permission level (equivalent to the Manage permission in Table 2) has the permission to modify the configuration of IoT devices;

[0092] The third permission level (equivalent to the Operate permission in Table 2) has the authority to control IoT devices to perform operations;

[0093] The fourth permission level (equivalent to the View permission in Table 2) has the permission to read and view device information of IoT devices;

[0094] The fifth permission level (equivalent to the None permission in Table 2) does not have permission to access IoT devices.

[0095] In an exemplary embodiment, the first permission information further includes target structure data, namely the aforementioned Target_struct. The target structure data is used to indicate the setting object corresponding to the permission level. This setting object can be the aforementioned IoT device, or it can be a function / module within the aforementioned IoT device.

[0096] In one example, the target structure data includes at least one of the following: endpoint, device type, and service cluster. Taking a Zigbee device as an example of an IoT device, a Zigbee device can be considered as a node in the network. This node may have multiple endpoints, each with a corresponding device type, and each endpoint may have multiple service clusters (or simply "cluster"). Furthermore, each cluster may have multiple attributes, each with its own data type and data content. For example, an IoT device may include two lights (denoted as light 1 and light 2) and one fan. This IoT device may include three endpoints (corresponding to the two lights and one fan mentioned above, each light / fan can be considered as an endpoint). The lights and fan belong to different device types. Under the lights, there may be multiple service clusters such as switch control, brightness adjustment, and color adjustment. Under the fans, there may also be multiple service clusters such as switch control, fan speed control, and cooling / heating control.

[0097] Therefore, when the first permission information includes target structure data, targeted permission settings can be applied to one or more settings objects in the IoT device, achieving more granular permission settings. For example, if the first permission information includes the permission level of Operate and the target structure data is Endpoint 0 (as in the example of light 1 above), it indicates that the first application grants the second application Operate permission to light 1 in the IoT device. As another example, if the first permission information includes the permission level of View and the target structure data is Endpoint 2 (as in the example of the fan above), it indicates that the first application grants the second application View permission to the fan in the IoT device.

[0098] It should be noted that the first permission information may include a set of corresponding permission levels and target structure data, or it may include multiple sets of corresponding permission levels and target structure data (to set access control permissions for multiple settings objects).

[0099] Furthermore, the first application and the second application can belong to different ecosystems or the same ecosystem; this application does not limit this. For an explanation of "ecosystem," please refer to the above; it will not be repeated here. In one example, the first application and the second application belong to two different ecosystems, for example, the first application belongs to the first ecosystem and the second application belongs to the second ecosystem. Thus, the technical solution of this application enables an application in one ecosystem to set device access control permissions for an application in another ecosystem, i.e., to set device access control permissions across ecosystems (or platforms), making the application scenarios more universal and applicable.

[0100] In summary, the technical solution provided in this application, by carrying the first permission information set by the first application in the open pairing command request sent by the first application to the IoT device, and using the first permission information to set the access control permissions of the second application for the IoT device, enables the first application to set the permissions of the second application before the second application establishes pairing with the IoT device, thereby achieving controllable permissions for the second application and helping to improve security.

[0101] For example, in one optional example, the first application can configure first permission information to set permissions for the second application other than administrator permissions, thereby ensuring that the administrator permissions of the first application cannot be changed. Furthermore, the second application does not have the ability to modify the device's ACL information after configuring the device. For example, in a home network, the mother holds the first application and the child holds the second application. For home devices, during the device configuration phase, the mother can use the first application to assign access control permissions other than administrator permissions to the child's second application, preventing the second application from modifying the device's operating permissions after successful access. Additionally, the first application can also configure first permission information to provide the second application with device resource information (i.e., the aforementioned target structure data) that can be accessed and controlled by the second application by default.

[0102] In an exemplary embodiment, such as Figure 4 As shown, after the first application sends an open pairing command request to the IoT device in step 310 above, the method further includes:

[0103] Step 320: The first application sends OT data sharing information to the second application.

[0104] Accordingly, the second application receives OT data sharing information from the first application.

[0105] OT data sharing information refers to OT data shared by a first application to a second application via out-of-band communication. Out-of-band communication here refers to methods that do not rely on IoT devices as intermediaries; for example, the first application sends OT data sharing information to the second application via email, file transfer, or other means.

[0106] OT data sharing information includes OT data, such as Version, VID (Vendor ID), PID (Product ID), Discriminator, PIN (Personal Identification Number), DNS-SD, and Special Instructions as mentioned above.

[0107] In one example, the OT data sharing information does not include first-level permission information. In this case, such as... Figure 4 As shown in Part A of the above, the method further includes the following steps 330 to 350:

[0108] Step 330: If the OT data sharing information does not include the first permission information, the second application sends an ACL information setting request carrying the second permission information to the IoT device; wherein, the second permission information is the access control permission for the IoT device that the second application sets for itself based on the default rules.

[0109] Accordingly, the IoT device receives an ACL information setting request from a second application, which includes second permission information.

[0110] Optionally, if the default rule is to set the permission level to Administer and the target data structure to the default resource information at the device's factory settings, then the second application can generate the aforementioned second permission information based on this default rule. This second permission information includes the Administer permission level and the default resource information at the device's factory settings. Of course, in some embodiments, the default rule can be other pre-defined rules, and this application does not limit this.

[0111] In some other embodiments, where the OT data sharing information includes the first permission information, the second application can also set access control permissions for the IoT device based on default rules and send an ACL information setting request carrying the second permission information to the IoT device. In this case, the IoT device also needs to perform step 340 below to determine whether the second permission information matches the first permission information.

[0112] Step 340: If the second permission information does not match the first permission information, the IoT device sets the permission information of the second application to the first permission information and stores the permission information of the second application in the ACL information.

[0113] The second permission information matching the first permission information can mean that the second permission information is the same as the first permission information; correspondingly, the second permission information not matching the first permission information can mean that the second permission information is not the same as the first permission information.

[0114] In one example, assuming the permission information includes permission levels, if the permission levels included in the second permission information are the same as those included in the first permission information, it means that the second permission information matches the first permission information; conversely, if the permission levels included in the second permission information are different from those included in the first permission information, it means that the second permission information does not match the first permission information.

[0115] In another example, assuming the permission information includes permission level and target structure data, if the permission level included in the second permission information is the same as the permission level included in the first permission information, and the target structure data included in the second permission information is also the same as the target structure data included in the first permission information, then the second permission information matches the first permission information; conversely, if the permission level included in the second permission information is different from the permission level included in the first permission information, and / or the target structure data included in the second permission information is different from the target structure data included in the first permission information, then the second permission information does not match the first permission information.

[0116] If the second permission information does not match the first permission information, then the first permission information shall prevail. That is, the IoT device sets the permission information of the second application to the first permission information and stores the permission information of the second application in the ACL information.

[0117] In addition, if the second permission information matches the first permission information, either the first permission information or the second permission information shall prevail. That is, the IoT device sets the permission information of the second application to the first permission information or the second permission information and stores the permission information of the second application in the ACL information.

[0118] Step 350: The IoT device sends the permission information of the second application to the second application.

[0119] Accordingly, the second application receives permission information from the IoT device.

[0120] Optionally, if the second permission information does not match the first permission information, the IoT device sends the permission information of the second application to the second application, and the permission information of the second application is the first permission information.

[0121] In this embodiment, the OT data sharing information sent by the first application to the second application may not include the first permission information. In this case, if the second application sets access control permissions for IoT devices based on default rules, the IoT device will use the first permission information set by the first application when storing the ACL information corresponding to the second application, thereby enabling the first application to control the permissions of the second application.

[0122] In another example, the OT data sharing information includes first permission information so that the second application carries this first permission information when sending an ACL information setting request to the IoT device. In this case, such as... Figure 4 As shown in Part B, the above method further includes the following steps 360-380:

[0123] Step 360: If the OT data sharing information includes the first permission information, the second application sends an ACL information setting request carrying the first permission information to the IoT device; wherein, the first permission information is set by the first application.

[0124] Accordingly, the IoT device receives an ACL information setting request from the second application, which includes first permission information.

[0125] If the OT data sharing information includes first permission information, then when the second application sets access control permissions for IoT devices, it will use the first permission information as the standard, instead of the default rules.

[0126] Step 370: If the ACL information setting request includes the first permission information verification, the IoT device sets the permission information of the second application as the first permission information and stores the permission information of the second application in the ACL information.

[0127] Step 380: If the verification of the first permission information in the ACL information setting request fails, the IoT device terminates the pairing process with the second application.

[0128] After receiving an ACL information setting request from a second application, the IoT device verifies whether the first permission information included in the ACL information setting request is the same as the first permission information provided by the first application. If they are the same, the verification passes; otherwise, if they are different, the verification fails. If the verification passes, the IoT device sets the second application's permission information as the first permission information and stores the second application's permission information in the ACL information. If the verification fails, the IoT device terminates the pairing process with the second application. Optionally, the IoT device also sends the verification result to the second application.

[0129] In this embodiment, the OT data sharing information sent by the first application to the second application includes first permission information. When the second application sets access control permissions for IoT devices, it uses the first permission information as the standard. When the IoT device stores the ACL information corresponding to the second application, it verifies the first permission information included in the ACL information setting request to verify whether the second application has adopted the access control permissions configured by the first application, thereby achieving controllable permissions of the first application to the second application.

[0130] Below, in conjunction with Figure 5 The following is a description of an exemplary embodiment provided in this application, which may include the following steps:

[0131] Step 501: As the first ecosystem of Node, APP A first generates OT data, which includes first permission information. This first permission information is set by APP A and is used to set the access control permissions of APP B for Node.

[0132] Step 502: The user of APP A decides whether to start the Node to enter pairing mode (so that the device can be connected to other ecosystem configurations);

[0133] Step 503: APP A sends an open pairing command request to Node, carrying OT data (which carries the aforementioned first permission information), and the data format is TLV;

[0134] Step 504: Node sends a return message to APP A indicating whether the pairing status has been successfully initiated;

[0135] Step 505: The Node publishes the DNS-SD data based on the DNS-SD data in the OT.

[0136] Step 506: APP A shares OT data (which may or may not contain first permission information) with APP B via out-of-band method. APP B belongs to the second ecosystem.

[0137] Step 507, APP B performs a DNS-SD data query;

[0138] Step 508: APP B detects the DNS-SD data sent by Node and resolves the IP address and port number;

[0139] Step 509: APP B and Node establish a secure connection based on the PIN in the OT data;

[0140] Step 510: APP B initiates device authentication for the Node and sends an operational CSR to the device. The device authentication process requires verification of the PAA and CD information built into the device. Since the device has been paired and authenticated by APP A, there is fabric object information generated by APP A.

[0141] Step 511: The Node sends the CSR, CD, and fabric object information to APP B (APP B checks the device's CD and whether the device has been certified by the CHIP certification authority).

[0142] In step 512, APP B decides whether to create a new fabric ID or use the fabric ID from the fabric object information;

[0143] Step 513: APP B sends the CSR information and fabric ID sent by the Node to CA B (APP B's certificate authority);

[0144] Step 514: CA B generates OC based on CSR data information and returns it to APP B along with the ecosystem's root certificate RC.B;

[0145] Step 515, APP B sends an ACL information setting request to the Node. The data includes: OC (including NodeID information, FabricID information, and operation certificate information generated for the device), root certificate RC.B, and the device's default ACL information (i.e., the second permission information, including privilege (permission) which defaults to administrator (administrator permission), and target_struct which can be the default resource information when the device is manufactured).

[0146] Step 516: Generate ACL information for APP B on the Node: Compare the second permission information in the ACL information setting request with the first permission information contained in the OT data. If they do not match, set the permission information of APP B as the first permission information.

[0147] Step 517: Return the ACL information of APP B, including the permission information of APP B;

[0148] Step 518, Node removes the OT data.

[0149] Below, in conjunction with Figure 6 The following is a description of an exemplary embodiment provided in this application, which may include the following steps:

[0150] Step 601: As the first ecosystem of Node, APP A first generates OT data, which includes first permission information. This first permission information is set by APP A and is used to set the access control permissions of APP B for Node.

[0151] Step 602: The user of APP A decides whether to start the Node to enter pairing mode (so that the device can be connected to other ecosystem configurations).

[0152] Step 603: APP A sends an open pairing command request to Node, carrying OT data (which carries the aforementioned first permission information), and the data format is TLV;

[0153] Step 604: Node sends a return message to APP A indicating whether the pairing status has been successfully initiated;

[0154] Step 605: The Node publishes the DNS-SD data based on the DNS-SD data in the OT.

[0155] Step 606: APP A shares OT data (which carries the first permission information) with APP B via out-of-band method. APP B belongs to the second ecosystem.

[0156] Step 607, APP B performs a DNS-SD data query;

[0157] Step 608: APP B detects the DNS-SD data sent by Node and resolves the IP address and port number;

[0158] Step 609: APP B and Node establish a secure connection based on the PIN in the OT data;

[0159] Step 610: APP B initiates device authentication for the Node and sends an operational CSR to the device. The device authentication process requires verification of the PAA and CD information built into the device. Since the device has been paired and authenticated by APP A, there is fabric object information generated by APP A.

[0160] Step 611: The Node sends the CSR, CD, and fabric object information to APP B (APP B checks the device's CD and whether the device has been certified by the CHIP certification authority).

[0161] In step 612, APP B decides whether to create a new fabric ID or use the fabric ID from the fabric object information;

[0162] Step 613: APP B sends the CSR information and fabric ID sent by the Node to CA B (APP B's certificate authority);

[0163] Step 614: CA B generates OC based on CSR data information and returns it to APP B along with the ecosystem's root certificate RC.B;

[0164] Step 615: APP B sets ACL information based on the first permission information;

[0165] Step 616, APP B sends an ACL information setting request to the Node. The data includes: OC (including NodeID information, FabricID information, and operation certificate information generated for the device), root certificate RC.B, and ACL information generated in step 615 (including first permission information).

[0166] Step 617: Node verifies whether the first permission information carried in the request is consistent with the first permission information in the OT data. If they are consistent, the verification passes; otherwise, the verification fails.

[0167] Step 618, verification passed, Node sets APP B's permission information as the first permission information and stores it in the ACL information;

[0168] Step 619, verification failed, Node terminates the pairing process with APP B;

[0169] Step 620: Node removes the OT data.

[0170] It should be noted that in the above method embodiments, the technical solution of this application is mostly described from the perspective of the interaction between the first application, the IoT device, and the second application. The steps executed by the IoT device can be implemented separately as a method for setting device access control permissions on the IoT device side; the steps executed by the first application can be implemented separately as a method for setting device access control permissions on the first application side; and the steps executed by the second application can be implemented separately as a method for setting device access control permissions on the second application side.

[0171] The following are embodiments of the apparatus of this application, which can be used to execute the embodiments of the method of this application. For details not disclosed in the embodiments of the apparatus of this application, please refer to the embodiments of the method of this application.

[0172] Please refer to Figure 7 This diagram illustrates a block diagram of a device access control permission setting apparatus according to an embodiment of this application. The apparatus has the functionality to implement the aforementioned method example on the IoT device side; this functionality can be implemented in hardware or by hardware executing corresponding software. The apparatus can be the IoT device described above, or it can be installed within an IoT device. Figure 7 As shown, the device 700 may include:

[0173] The request receiving module 710 is used to receive an open pairing command request from a first application, wherein the open pairing command request is a request from the first application to enable the pairing function of the IoT device; wherein the open pairing command request includes first permission information set by the first application, and the first permission information is used to set the access control permissions of the second application for the IoT device.

[0174] In an optional embodiment, the first permission information includes a permission level.

[0175] Optionally, the first permission information further includes target structure data, which is used to indicate the setting object corresponding to the permission level.

[0176] Optionally, the target structure data includes at least one of the following: endpoint, device type, and service cluster.

[0177] Optionally, the permission level is any one of the following:

[0178] First level of access, with permission to view and modify the ACL cluster to which the IoT device belongs;

[0179] The second level of access grants the user the authority to modify the configuration of the IoT device.

[0180] The third level of authority grants the user the permission to control the IoT devices to perform operations.

[0181] The fourth permission level grants the user the authority to read and view the device information of the IoT device.

[0182] Level 5 access control: does not have permission to access the IoT device.

[0183] In one alternative embodiment, the first application and the second application belong to different ecosystems.

[0184] In an optional embodiment, the open pairing command request includes OT data, which includes the first permission information.

[0185] In one alternative embodiment, such as Figure 7 As shown, the device 700 further includes:

[0186] The information storage module 720 is used to store ACL information corresponding to the second application based on the first permission information.

[0187] In one example, the information storage module 720 is used for:

[0188] Receive an ACL information setting request from the second application, the ACL information setting request including second permission information, the second permission information being the access control permissions for the IoT device set by the second application for itself based on default rules;

[0189] If the second permission information does not match the first permission information, then the permission information of the second application is set to the first permission information, and the permission information of the second application is stored in the ACL information;

[0190] Send the permission information of the second application to the second application.

[0191] In another example, the information storage module 720 is used for:

[0192] Receive an ACL information setting request from the second application, wherein the ACL information setting request includes the first permission information, which is sent by the first application to the second application;

[0193] If the ACL information setting request includes the first permission information verification, then the permission information of the second application is set to the first permission information, and the permission information of the second application is stored in the ACL information;

[0194] If the ACL information setting request includes a failed verification of the first permission information, the pairing process with the second application is terminated.

[0195] Please refer to Figure 8 This diagram illustrates a block diagram of a device access control permission setting apparatus according to another embodiment of this application. The apparatus has the functionality to implement the method example described above on the first application side; this functionality can be implemented in hardware or by hardware executing corresponding software. The apparatus can be the first terminal device described above, or it can be located within the first terminal device. Figure 8 As shown, the device 800 may include:

[0196] The request sending module 810 is used to send an open pairing command request to an IoT device. The open pairing command request is a request from a first application to the IoT device to enable the pairing function. The open pairing command request includes first permission information set by the first application, which is used to set access control permissions for the second application for the IoT device.

[0197] In an optional embodiment, the first permission information includes a permission level.

[0198] Optionally, the first permission information further includes target structure data, which is used to indicate the setting object corresponding to the permission level.

[0199] Optionally, the target structure data includes at least one of the following: endpoint, device type, and service cluster.

[0200] Optionally, the permission level is any one of the following:

[0201] First level of access, with permission to view and modify the ACL cluster to which the IoT device belongs;

[0202] The second level of access grants the user the authority to modify the configuration of the IoT device.

[0203] The third level of authority grants the user the permission to control the IoT devices to perform operations.

[0204] The fourth permission level grants the user the authority to read and view the device information of the IoT device.

[0205] Level 5 access control: does not have permission to access the IoT device.

[0206] In one alternative embodiment, the first application and the second application belong to different ecosystems.

[0207] In an optional embodiment, the open pairing command request includes OT data, which includes the first permission information.

[0208] In one alternative embodiment, such as Figure 8 As shown, the device 800 further includes:

[0209] The information sending module 820 is used to send OT data sharing information to the second application, wherein the OT data sharing information does not include the first permission information.

[0210] In one alternative embodiment, such as Figure 8 As shown, the device 800 further includes:

[0211] The information sending module 820 is used to send OT data sharing information to the second application. The OT data sharing information includes the first permission information, so that the second application carries the first permission information when sending an ACL information setting request to the IoT device.

[0212] Please refer to Figure 9 This diagram illustrates a block diagram of a device access control permission setting apparatus according to another embodiment of this application. The apparatus has the functionality to implement the method example described above for the second application side; this functionality can be implemented in hardware or by hardware executing corresponding software. The apparatus can be the second terminal device described above, or it can be located within a second terminal device. Figure 9 As shown, the device 900 may include:

[0213] The information receiving module 910 is used to receive OT data sharing information from the first application.

[0214] The setting request module 920 is used to send an ACL information setting request carrying the first permission information to the IoT device when the OT data sharing information includes the first permission information; wherein the first permission information is set by the first application, and the first permission information is used to set the access control permissions of the second application for the IoT device.

[0215] In an optional embodiment, the first permission information includes a permission level.

[0216] Optionally, the first permission information further includes target structure data, which is used to indicate the setting object corresponding to the permission level.

[0217] Optionally, the target structure data includes at least one of the following: endpoint, device type, and service cluster.

[0218] Optionally, the permission level is any one of the following:

[0219] First level of access, with permission to view and modify the ACL cluster to which the IoT device belongs;

[0220] The second level of access grants the user the authority to modify the configuration of the IoT device.

[0221] The third level of authority grants the user the permission to control the IoT devices to perform operations.

[0222] The fourth permission level grants the user the authority to read and view the device information of the IoT device.

[0223] Level 5 access control: does not have permission to access the IoT device.

[0224] In one alternative embodiment, the first application and the second application belong to different ecosystems.

[0225] In an optional embodiment, the setting request module 920 is further configured to send an ACL information setting request carrying second permission information to the IoT device if the first permission information is not included in the OT data sharing information; wherein, the second permission information is the access control permission for the IoT device set by the second application for itself based on default rules.

[0226] Optionally, the device 900 further includes: a permission receiving module (not shown in the figure), configured to receive permission information of the second application from the IoT device; wherein the permission information of the second application is set by the IoT device based on the first permission information when it determines that the second permission information does not match the first permission information.

[0227] It should be noted that the device provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules according to actual needs, that is, the content structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0228] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0229] Please refer to Figure 10This illustration shows a schematic diagram of the structure of an Internet of Things (IoT) device 100 provided in one embodiment of this application. The IoT device 100 can be used to implement the aforementioned method for setting device access control permissions on the IoT device side. The IoT device 100 may include: a processor 101, a receiver 102, a transmitter 103, a memory 104, and a bus 105.

[0230] The processor 101 includes one or more processing cores. The processor 101 executes various functional applications and information processing by running software programs and modules.

[0231] The receiver 102 and the transmitter 103 can be implemented as a communication component, which can be a communication chip.

[0232] The memory 104 is connected to the processor 101 via the bus 105.

[0233] The memory 104 can be used to store a computer program, and the processor 101 is used to execute the computer program to implement the various steps performed by the Internet of Things device in the above method embodiments.

[0234] Furthermore, the memory 104 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, including but not limited to: RAM (Random-Access Memory) and ROM (Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other solid-state storage technologies, CD-ROM (Compact Disc Read-Only Memory), DVD (Digital Video Disc) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices.

[0235] In an exemplary embodiment, the Internet of Things device includes a processor, a memory, and a transceiver (the transceiver may include a receiver and a transmitter, the receiver being used to receive information and the transmitter being used to send information);

[0236] The transceiver is used to receive an open pairing command request from a first application, which is a request from the first application to enable the pairing function of the IoT device; wherein, the open pairing command request includes first permission information set by the first application, which is used to set access control permissions for the IoT device by the second application.

[0237] In an optional embodiment, the first permission information includes a permission level.

[0238] Optionally, the first permission information further includes target structure data, which is used to indicate the setting object corresponding to the permission level.

[0239] Optionally, the target structure data includes at least one of the following: endpoint, device type, and service cluster.

[0240] Optionally, the permission level is any one of the following:

[0241] First level of access, with permission to view and modify the ACL cluster to which the IoT device belongs;

[0242] The second level of access grants the user the authority to modify the configuration of the IoT device.

[0243] The third level of authority grants the user the permission to control the IoT devices to perform operations.

[0244] The fourth permission level grants the user the authority to read and view the device information of the IoT device.

[0245] Level 5 access control: does not have permission to access the IoT device.

[0246] In one alternative embodiment, the first application and the second application belong to different ecosystems.

[0247] In an optional embodiment, the open pairing command request includes OT data, which includes the first permission information.

[0248] In an optional embodiment, the processor is configured to store ACL information corresponding to the second application based on the first permission information.

[0249] In one example, the transceiver is also configured to receive an ACL information setting request from the second application, the ACL information setting request including second permission information, the second permission information being the access control permissions for the IoT device set by the second application for itself based on default rules;

[0250] The processor is further configured to, if the second permission information does not match the first permission information, set the permission information of the second application to the first permission information and store the permission information of the second application in the ACL information;

[0251] The transceiver is also used to send permission information of the second application to the second application.

[0252] In another example, the transceiver is also configured to receive an ACL information setting request from the second application, the ACL information setting request including the first permission information, the first permission information being sent by the first application to the second application;

[0253] The processor is further configured to, if the ACL information setting request includes the first permission information and the verification passes, set the permission information of the second application to the first permission information and store the permission information of the second application in the ACL information; if the ACL information setting request includes the first permission information and the verification fails, terminate the pairing process with the second application.

[0254] Please refer to Figure 11 This illustration shows a schematic diagram of the structure of a terminal device 111 provided in one embodiment of this application. The terminal device 111 can be used to implement the aforementioned method for setting device access control permissions on the first application / second application side. The terminal device 110 may include: a processor 111, a receiver 112, a transmitter 113, a memory 114, and a bus 115.

[0255] The processor 111 includes one or more processing cores. The processor 111 executes various functional applications and information processing by running software programs and modules.

[0256] The receiver 112 and the transmitter 113 can be implemented as a communication component, which can be a communication chip.

[0257] The memory 114 is connected to the processor 111 via the bus 115.

[0258] The memory 114 can be used to store a computer program, and the processor 111 is used to execute the computer program to implement the various steps of the first application / second application execution in the above method embodiments.

[0259] Furthermore, the memory 114 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, including but not limited to: magnetic disks or optical disks, electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), read-only memory (ROM), magnetic storage, flash memory, and programmable read-only memory (PROM).

[0260] In an exemplary embodiment, the terminal device includes a processor, a memory, and a transceiver (the transceiver may include a receiver and a transmitter, the receiver being used to receive information and the transmitter being used to send information).

[0261] In the case where the terminal device is a first terminal device running a first application,

[0262] The transceiver is used to send an open pairing command request to the IoT device. The open pairing command request is a request from the first application to the IoT device to enable the pairing function. The open pairing command request includes first permission information set by the first application, which is used to set access control permissions for the second application for the IoT device.

[0263] In an optional embodiment, the first permission information includes a permission level.

[0264] Optionally, the first permission information further includes target structure data, which is used to indicate the setting object corresponding to the permission level.

[0265] Optionally, the target structure data includes at least one of the following: endpoint, device type, and service cluster.

[0266] Optionally, the permission level is any one of the following:

[0267] First level of access, with permission to view and modify the ACL cluster to which the IoT device belongs;

[0268] The second level of access grants the user the authority to modify the configuration of the IoT device.

[0269] The third level of authority grants the user the permission to control the IoT devices to perform operations.

[0270] The fourth permission level grants the user the authority to read and view the device information of the IoT device.

[0271] Level 5 access control: does not have permission to access the IoT device.

[0272] In one alternative embodiment, the first application and the second application belong to different ecosystems.

[0273] In an optional embodiment, the open pairing command request includes OT data, which includes the first permission information.

[0274] In an optional embodiment, the transceiver is further configured to send OT data sharing information to the second application, wherein the OT data sharing information does not include the first permission information.

[0275] In an optional embodiment, the transceiver is further configured to send OT data sharing information to the second application, the OT data sharing information including the first permission information, so that the second application carries the first permission information when sending an ACL information setting request to the IoT device.

[0276] In the case where the terminal device is a second terminal device running a second application,

[0277] The transceiver is used to receive OT data sharing information from the first application;

[0278] The transceiver is further configured to send an ACL information setting request carrying the first permission information to the IoT device when the OT data sharing information includes the first permission information; wherein the first permission information is set by the first application and is used to set the access control permissions of the second application for the IoT device.

[0279] In an optional embodiment, the first permission information includes a permission level.

[0280] Optionally, the first permission information further includes target structure data, which is used to indicate the setting object corresponding to the permission level.

[0281] Optionally, the target structure data includes at least one of the following: endpoint, device type, and service cluster.

[0282] Optionally, the permission level is any one of the following:

[0283] First level of access, with permission to view and modify the ACL cluster to which the IoT device belongs;

[0284] The second level of access grants the user the authority to modify the configuration of the IoT device.

[0285] The third level of authority grants the user the permission to control the IoT devices to perform operations.

[0286] The fourth permission level grants the user the authority to read and view the device information of the IoT device.

[0287] Level 5 access control: does not have permission to access the IoT device.

[0288] In one alternative embodiment, the first application and the second application belong to different ecosystems.

[0289] In an optional embodiment, the transceiver is further configured to send an ACL information setting request carrying second permission information to the IoT device if the first permission information is not included in the OT data sharing information; wherein the second permission information is the access control permission for the IoT device set by the second application for itself based on default rules.

[0290] Optionally, the transceiver is further configured to receive permission information of the second application from the IoT device; wherein the permission information of the second application is set by the IoT device based on the first permission information when it determines that the second permission information does not match the first permission information.

[0291] An exemplary embodiment of this application also provides a computer-readable storage medium storing a computer program for execution by a processor to implement the above-described method for setting device access control permissions on the IoT device side, or the above-described method for setting device access control permissions on the first application side, or the above-described method for setting device access control permissions on the second application side.

[0292] For example, a computer-readable storage medium storing a computer program for execution by a processor of an Internet of Things (IoT) device to implement the above-described method for setting device access control permissions on the IoT device side.

[0293] For example, a computer-readable storage medium storing a computer program for execution by a processor of a terminal device to implement the aforementioned method for setting device access control permissions on the first application side.

[0294] For example, a computer-readable storage medium storing a computer program for execution by a processor of a terminal device to implement the above-described method for setting device access control permissions on the second application side.

[0295] An exemplary embodiment of this application also provides a chip, the chip including programmable logic circuits and / or program instructions, which, when the chip is running, are used to implement the above-mentioned method for setting device access control permissions on the IoT device side, or the above-mentioned method for setting device access control permissions on the first application side, or the above-mentioned method for setting device access control permissions on the second application side.

[0296] For example, a chip including programmable logic circuits and / or program instructions, when the chip is running on an IoT device, is used to implement the above-mentioned method for setting device access control permissions on the IoT device side.

[0297] For example, a chip including programmable logic circuits and / or program instructions, when the chip is running on a terminal device where a first application resides, is used to implement the aforementioned method for setting device access control permissions on the first application side.

[0298] For example, a chip including programmable logic circuits and / or program instructions, when the chip is running on a terminal device where a second application resides, is used to implement the aforementioned method for setting device access control permissions on the second application side.

[0299] An exemplary embodiment of this application also provides a computer program product or computer program, the computer program product or computer program including computer instructions, the computer instructions being stored in a computer-readable storage medium, and a processor reading from the computer-readable storage medium and executing the computer instructions to implement the above-described method for setting device access control permissions on the IoT device side, or the above-described method for setting device access control permissions on the first application side, or the above-described method for setting device access control permissions on the second application side.

[0300] For example, a computer program product or computer program includes computer instructions stored in a computer-readable storage medium. The processor of an IoT device reads and executes the computer instructions from the computer-readable storage medium to implement the above-mentioned method for setting device access control permissions on the IoT device side.

[0301] For example, a computer program product or computer program includes computer instructions stored in a computer-readable storage medium. The processor of a terminal device reads and executes the computer instructions from the computer-readable storage medium to implement the device access control permission setting method on the first application side described above.

[0302] For example, a computer program product or computer program includes computer instructions stored in a computer-readable storage medium, and the processor of a terminal device reads and executes the computer instructions from the computer-readable storage medium to implement the above-described method for setting device access control permissions on the second application side.

[0303] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0304] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method of setting a control right of a device, characterized by, The method is executed by an Internet of Things (IoT) device, and the method includes: The system receives an "Open Pairing Command Request" from a first application, whereby the first application requests the IoT device to enable pairing functionality. The "Open Pairing Command Request" includes first permission information set by the first application, which is used to set access control permissions for the second application regarding the IoT device. Receive an ACL information setting request from the second application; The ACL information setting request includes second permission information, which is the access control permissions for the IoT device set by the second application for itself based on default rules. If the second permission information does not match the first permission information, the permission information of the second application is set to the first permission information, and the permission information of the second application is stored in the ACL information; the permission information of the second application is then sent to the second application; or... The ACL information setting request includes the first permission information, which is sent by the first application to the second application. If the verification of the first permission information in the ACL information setting request passes, the permission information of the second application is set to the first permission information, and the permission information of the second application is stored in the ACL information. If the verification of the first permission information in the ACL information setting request fails, the pairing process with the second application is terminated.

2. The method of claim 1, wherein, The first permission information includes the permission level.

3. The method of claim 2, wherein, The first permission information also includes target structure data, which is used to indicate the setting object corresponding to the permission level.

4. The method of claim 3, wherein, The target structure data includes at least one of the following: endpoint, device type, service cluster.

5. The method according to any one of claims 2 to 4, characterized in that, The permission level is any one of the following: First level of access, with permission to view and modify the Access Control List (ACL) cluster to which the IoT device belongs; The second level of access grants the user the authority to modify the configuration of the IoT device. The third level of authority grants the user the permission to control the IoT devices to perform operations. The fourth permission level grants the user the authority to read and view the device information of the IoT device. Level 5 access control: does not have permission to access the IoT device.

6. The method according to any one of claims 1 to 4, characterized in that, The first application and the second application belong to different ecosystems.

7. The method according to any one of claims 1 to 4, characterized in that, The open pairing command request includes self-registered token (OT) data, and the OT data includes the first permission information.

8. A method of setting access control rights of a device, characterized by, The method is executed by a first application, and the method includes: Sending an open pairing command request to an IoT device, wherein the open pairing command request is a request from the first application to the IoT device to enable pairing functionality; wherein the open pairing command request includes first permission information set by the first application, the first permission information being used to set access control permissions for the second application regarding the IoT device; and... Send OT data sharing information to the second application. Wherein, the OT data sharing information does not include the first permission information; or, The OT data sharing information includes the first permission information, so that when the second application sends an ACL information setting request to the IoT device, it carries the first permission information.

9. The method of claim 8, wherein, The first permission information includes the permission level.

10. The method of claim 9, wherein, The first permission information also includes target structure data, which is used to indicate the setting object corresponding to the permission level.

11. The method of claim 10, wherein, The target structure data includes at least one of the following: endpoint, device type, service cluster.

12. The method according to any one of claims 9 to 11, characterized in that, The permission level is any one of the following: First level of access, with permission to view and modify the Access Control List (ACL) cluster to which the IoT device belongs; The second level of access grants the user the authority to modify the configuration of the IoT device. The third level of authority grants the user the permission to control the IoT devices to perform operations. The fourth permission level grants the user the authority to read and view the device information of the IoT device. Level 5 access control: does not have permission to access the IoT device.

13. The method according to any one of claims 8 to 11, characterized in that, The first application and the second application belong to different ecosystems.

14. The method according to any one of claims 8 to 11, characterized in that, The open pairing command request includes self-registered token (OT) data, and the OT data includes the first permission information.

15. A method of setting access control rights of a device, characterized by, The method is executed by a second application, and the method includes: Receive self-registered token OT data sharing information from the first application; If the OT data sharing information includes first permission information, a request to set access control list (ACL) information carrying the first permission information is sent to the IoT device; wherein, the first permission information is set by the first application, and the first permission information is used to set the access control permissions of the second application for the IoT device; If the first permission information is not included in the OT data sharing information, an ACL information setting request carrying the second permission information is sent to the IoT device; wherein, the second permission information is the access control permission for the IoT device set by the second application for itself based on default rules.

16. The method of claim 15, wherein, The first permission information includes the permission level.

17. The method of claim 16, wherein, The first permission information also includes target structure data, which is used to indicate the setting object corresponding to the permission level.

18. The method of claim 17, wherein, The target structure data includes at least one of the following: endpoint, device type, service cluster.

19. The method according to any one of claims 16 to 18, characterized in that, The permission level is any one of the following: First-level access, with permission to view and modify the ACL cluster to which the IoT device belongs; The second level of access grants the user the authority to modify the configuration of the IoT device. The third level of authority grants the user the permission to control the IoT devices to perform operations. The fourth permission level grants the user the authority to read and view the device information of the IoT device. Level 5 access control: does not have permission to access the IoT device.

20. The method according to any one of claims 15 to 18, characterized in that, The first application and the second application belong to different ecosystems.

21. The method of claim 15, wherein, After sending the ACL information setting request carrying the second permission information to the IoT device, the method further includes: The device receives permission information from the second application of the IoT device; wherein the permission information of the second application is set by the IoT device based on the first permission information when it determines that the second permission information does not match the first permission information.

22. A device for setting device access control permissions, characterized in that, The device includes: A request receiving module is configured to receive an open pairing command request from a first application, wherein the open pairing command request is a request from the first application to enable pairing functionality on an IoT device; wherein the open pairing command request includes first permission information set by the first application, the first permission information being used to set access control permissions for the IoT device by a second application; and... An information storage module is used to receive ACL information setting requests from the second application. The ACL information setting request includes second permission information, which is the access control permissions for the IoT device set by the second application for itself based on default rules. If the second permission information does not match the first permission information, the permission information of the second application is set to the first permission information, and the permission information of the second application is stored in the ACL information; the permission information of the second application is then sent to the second application; or... The ACL information setting request includes the first permission information, which is sent by the first application to the second application. If the verification of the first permission information in the ACL information setting request passes, the permission information of the second application is set to the first permission information, and the permission information of the second application is stored in the ACL information. If the verification of the first permission information in the ACL information setting request fails, the pairing process with the second application is terminated.

23. The apparatus of claim 22, wherein, The first permission information includes the permission level.

24. The apparatus of claim 23, wherein, The first permission information also includes target structure data, which is used to indicate the setting object corresponding to the permission level.

25. The apparatus of claim 24, wherein, The target structure data includes at least one of the following: endpoint, device type, service cluster.

26. The apparatus of any one of claims 23-25, wherein, The permission level is any one of the following: First level of access, with permission to view and modify the Access Control List (ACL) cluster to which the IoT device belongs; The second level of access grants the user the authority to modify the configuration of the IoT device. The third level of authority grants the user the permission to control the IoT devices to perform operations. The fourth permission level grants the user the authority to read and view the device information of the IoT device. Level 5 access control: does not have permission to access the IoT device.

27. The apparatus of any one of claims 22-25, wherein, The first application and the second application belong to different ecosystems.

28. The apparatus of any one of claims 22-25, wherein, The open pairing command request includes self-registered token (OT) data, and the OT data includes the first permission information.

29. An apparatus for setting access control rights of a device, characterized by The device includes: A request sending module is used to send an open pairing command request to an IoT device. The open pairing command request is a request from a first application to the IoT device to enable pairing functionality. The open pairing command request includes first permission information set by the first application, which is used to set access control permissions for the second application regarding the IoT device. The information sending module is used to send OT data sharing information to the second application. Wherein, the OT data sharing information does not include the first permission information; or, The OT data sharing information includes the first permission information, so that when the second application sends an ACL information setting request to the IoT device, it carries the first permission information.

30. The apparatus of claim 29, wherein, The first permission information includes the permission level.

31. The apparatus of claim 30, wherein, The first permission information also includes target structure data, which is used to indicate the setting object corresponding to the permission level.

32. The apparatus of claim 31, wherein, The target structure data includes at least one of the following: endpoint, device type, service cluster.

33. The apparatus of any one of claims 30 to 32, wherein, The permission level is any one of the following: First level of access, with permission to view and modify the Access Control List (ACL) cluster to which the IoT device belongs; The second level of access grants the user the authority to modify the configuration of the IoT device. The third level of authority grants the user the permission to control the IoT devices to perform operations. The fourth permission level grants the user the authority to read and view the device information of the IoT device. Level 5 access control: does not have permission to access the IoT device.

34. The apparatus of any one of claims 29-32, wherein, The first application and the second application belong to different ecosystems.

35. The apparatus according to any one of claims 29 to 32, characterized in that, The open pairing command request includes self-registered token (OT) data, and the OT data includes the first permission information.

36. A device for setting device access control permissions, characterized in that, The device includes: The information receiving module is used to receive self-registered token OT data sharing information from the first application; The setting request module is configured to send an Access Control List (ACL) information setting request carrying the first permission information to the IoT device when the OT data sharing information includes the first permission information; wherein the first permission information is set by the first application and is used to set the access control permissions of the second application for the IoT device; the setting request module is further configured to send an ACL information setting request carrying the second permission information to the IoT device when the OT data sharing information does not include the first permission information; wherein the second permission information is the access control permissions for the IoT device set by the second application for itself based on default rules.

37. The apparatus according to claim 36, characterized in that, The first permission information includes the permission level.

38. The apparatus according to claim 37, characterized in that, The first permission information also includes target structure data, which is used to indicate the setting object corresponding to the permission level.

39. The apparatus according to claim 38, characterized in that, The target structure data includes at least one of the following: endpoint, device type, service cluster.

40. The apparatus according to any one of claims 37 to 39, characterized in that, The permission level is any one of the following: First-level access, with permission to view and modify the ACL cluster to which the IoT device belongs; The second level of access grants the user the authority to modify the configuration of the IoT device. The third level of authority grants the user the permission to control the IoT devices to perform operations. The fourth permission level grants the user the authority to read and view the device information of the IoT device. Level 5 access control: does not have permission to access the IoT device.

41. The apparatus according to any one of claims 36 to 39, characterized in that, The first application and the second application belong to different ecosystems.

42. The apparatus according to claim 36, characterized in that, The device further includes: The permission receiving module is used to receive permission information from the second application of the IoT device; wherein the permission information of the second application is set by the IoT device based on the first permission information when it is determined that the second permission information does not match the first permission information.

43. An Internet of Things (IoT) device, characterized in that, The IoT device includes a transceiver; The transceiver is configured to receive an open pairing command request from a first application, wherein the open pairing command request is a request from the first application to enable the pairing function of the IoT device; wherein the open pairing command request includes first permission information set by the first application, the first permission information being used to set access control permissions for the IoT device by the second application; The transceiver is also used to receive ACL information setting requests from the second application. The ACL information setting request includes second permission information, which is the access control permissions for the IoT device set by the second application for itself based on default rules. If the second permission information does not match the first permission information, the permission information of the second application is set to the first permission information, and the permission information of the second application is stored in the ACL information; the permission information of the second application is then sent to the second application; or... The ACL information setting request includes the first permission information, which is sent by the first application to the second application. If the verification of the first permission information in the ACL information setting request passes, the permission information of the second application is set to the first permission information, and the permission information of the second application is stored in the ACL information. If the verification of the first permission information in the ACL information setting request fails, the pairing process with the second application is terminated.

44. A terminal device, characterized in that, The terminal device includes a transceiver; The transceiver is used to send an open pairing command request to an IoT device. The open pairing command request is a request from a first application to enable the pairing function of the IoT device. The open pairing command request includes first permission information set by the first application, which is used to set access control permissions for the second application for the IoT device. The transceiver is also used to send OT data sharing information to the second application after sending the open pairing command request to the IoT device; Wherein, the OT data sharing information does not include the first permission information; or, The OT data sharing information includes the first permission information, so that when the second application sends an ACL information setting request to the IoT device, it carries the first permission information.

45. A terminal device, characterized in that, The terminal device includes a transceiver; The transceiver is used to receive self-registered token OT data sharing information from the first application. The transceiver is further configured to send an Access Control List (ACL) information setting request carrying the first permission information to the IoT device when the OT data sharing information includes the first permission information; wherein the first permission information is set by the first application and is used to set the access control permissions of the second application for the IoT device; The transceiver is further configured to send an ACL information setting request carrying second permission information to the IoT device when the first permission information is not included in the OT data sharing information; wherein the second permission information is the access control permission for the IoT device set by the second application for itself based on default rules.

46. ​​A computer-readable storage medium, characterized in that, The storage medium stores a computer program that is executed by a processor to implement the device access control permission setting method as described in any one of claims 1 to 7, or the device access control permission setting method as described in any one of claims 8 to 14, or the device access control permission setting method as described in any one of claims 15 to 21.

47. A chip, characterized in that, The chip includes programmable logic circuits and / or program instructions, which, when the chip is running, are used to implement the device access control permission setting method as described in any one of claims 1 to 7, or the device access control permission setting method as described in any one of claims 8 to 14, or the device access control permission setting method as described in any one of claims 15 to 21.

48. A computer program product or computer program, characterized in that, The computer program product or computer program includes computer instructions stored in a computer-readable storage medium. A processor reads and executes the computer instructions from the computer-readable storage medium to implement the device access control permission setting method as described in any one of claims 1 to 7, or the device access control permission setting method as described in any one of claims 8 to 14, or the device access control permission setting method as described in any one of claims 15 to 21.

Images