确定Matter设备本地访问控制权限的方法和系统

技术领域

本申请涉及智能家居技术领域，尤其涉及一种确定Matter设备本地访问控制权限的方法和系统。

背景技术

Matter协议是CSA联盟与Google、Amazon、Apple共同推进的物联网标准连接方案，旨在实现所有IoT设备的兼容性，实现一套协议控制所有设备。

Matter协议中有Fabric(对应中文为“织物”)功能，其解释为：同一网络下的一组设备共享相同的安全域，允许节点之间安全通信，这组设备称为Fabric。可以把Fabric比作一张网，每个Matter设备都是这张网上的一个节点，每个节点在fabric下都有一个唯一的节点标识nodeID，所以如果想要使用Matter设备，首先需要创建fabric。

目前各大厂商的客户端APP中，基本都是以家庭作为载体，用来展示相关设备，用户添加设备时，需要先创建一个家庭，即用户与家庭建立关系，然后配网之后，设备就与家庭建立关联关系，进而产生用户与设备之间的关系。Matter设备也不例外，其如果想在APP里进行使用，一般的做法通常是为家庭创建一个1对1的fabric，然后在家庭对应的fabric里为设备分为对应的节点nodeID，这样就达到的Matter设备的接入。实际上，是各个节点根据秘钥或凭证组成一个fabric，以家庭为载体创建fabric是比较常见和容易理解的方式。另外每个节点对应的设备内部都维护了一个ACL(Access Control List，访问控制列表)。ACL功能旨在确保只有授权的节点才能通过交互模型访问数据模型公开给定的应用层功能，访问控制是安全通道和交互模型之间的基本链接。所以ACL功能中其中非常重要的一点是：授予其他节点访问和控制此节点的能力，并且授予是有权限等级的，在一个具体实施例中，权限等级如表1所示：

表1

在表1中，等级越大，授予的权限基本越高，Administer是最高权限，为管理员角色的权限，这个权限比较特殊，因为它跟访问控制集群有关，而且只有授予此权限级别的节点才有修改访问控制的能力；当节点被授予特定权限时，它也被隐式授予所有逻辑上较低的权限级别，例如赋值某个节点的权限等级为5，那么该节点自动拥有等级1、2、3和4的功能权限。

按照Matter官方给出的规范里，在Matter设备激活阶段，会通过内部方法自动为整个节点默认创建一个授予权限等级为Administer的权限控制列表项，并把它加入到ACL中。例如，Matter设备授予索引为1的Fabric下的一个nodeID为0xAAAA_AAAA_AAAA_AAAA的节点的访问控制权限为Administer，授予之后，此节点就有了访问控制当前Matter设备的能力。例如现在需要通过客户端APP来控制Matter设备，首先要通过客户端APP与Matter设备建立会话，然后就需要传入访问控制的nodeID(前述0xAAAA_AAAA_AAAA_AAAA)进行验证是否有权限。验证通过之后，会话才能建立成功，后续才能进行控制。

按照Matter官方给出的规范，设备激活阶段，这个授予权限为Administer的nodeID可以自行定义，只要不超出nodeID的设置范围即可[范围：总体范围在0x0000_0000_0000_0001(10进制：1)到0xFFFF_FFEF_FFFF_FFFF(10进制：18446744004990075000)之间]。按照以往的设计方案，技术人员在做Matter设备ACL方案时，通常的做法都是同一个fabric下通过算法生成一个nodeID，为一对一关系，然后设计激活时设置相关的权限等级为administer，并写入到Matter设备的ACL里。然后后续任何客户端APP或者其他Matter设备想要访问或控制此设备时，都是通过这个生成的nodeID与此设备建立会话。

发明内容

发明人发现，对于现有技术中“同一个fabric下通过算法生成一对一的nodeID”的方式，会带来加大的安全风险：首先，如果nodeID与fabric的关联关系不通过云端来维护，那么每次创建一个新的fabric网络时，为了保持同一个设备可以被多个客户端APP进行控制，那么就需要将所有客户端APP的nodeID是一样的，即每个fabric对应的nodeID都是相同的，这样的设计虽然做法很简单，但是安全性大大降低，另外不通过云端来维护关系的方案很容易造成nodeID生成重复导致业务受损的问题；其次，如果nodeID与fabric的关联关系通过云端来维护，这样每次创建新的fabric时，可以为之随机分配一个一对一的nodeID，这样安全性确实增高了，但是相同的fabric授权多个用户进行使用。那么每个用户可以知道其他用户也是通过相同的nodeID对设备进行访问控制，那么安全性还是没有得到有效保证。

有鉴于此，本申请提供一种确定Matter设备本地访问控制权限的方案，在本方案中，为每个用户在当前fabric里分配唯一的访问控制的唯一标识(例如，nodeID)，从而提高系统的安全性。

根据本申请的第一个方面，本申请提供一种确定Matter设备本地访问控制权限的方法，应用于云端服务器，其包括：

为用户配备在当前fabric下的唯一标识；

针对所述fabric下的Matter设备，为所述用户确定控制权限等级；以及

将所述唯一标识和所述控制权限等级分享至所述Matter设备，与所述Matter设备进行同步。

根据本申请的第二个方面，本申请提供一种确定Matter设备本地访问控制权限的系统，包括Matter设备、客户端和云端服务器，其中：

所述云端服务器用于执行如第一个方面所述的方法；

所述Matter设备响应于所述客户端的同步状态更新消息，向所述云端服务器发送访问控制权限请求，并接收所述云端服务器发送的唯一标识和控制权限等级；或者，接收来自所述客户端的所述唯一标识和所述控制权限等级；

所述客户端向所述Matter设备发送同步状态更新消息；或者向所述云端服务器发送访问控制权限请求，接收所述云端服务器发送的唯一标识和控制权限等级，并将所述唯一标识和所述控制权限等级发送至所述Matter设备。

根据本申请的第三个方面，提供一种电子设备，其特征在于，包括：

处理器；以及

存储器，存储有计算机指令，当所述计算机指令被所述处理器执行时，使得所述处理器执行如第一个方面所述的方法。

根据本申请的第四个方面，提供一种非瞬时性计算机存储介质，存储有计算机程序，当所述计算机程序被多个处理器执行时，使得所述处理器执行如第一个方面所述的方法。

根据本申请提供的确定Matter设备本地访问控制权限的方法和系统，首先，使得每个用户在当前的fabric里拥有访问控制的唯一标识，解决了不同用户对于相同设备的控制问题，并且安全性得到的有效保证；其次，云端分配了Matter设备自身的唯一标识以及为用户分配访问控制的唯一标识，不仅有效解决了唯一标识本地分配时带来的重复问题，而且，由于云端是针对每个用户的账号进行唯一标识的分配，解决多客户端的数据同步问题；另外，Matter设备的ACL权限进行云端管理，通过Matter设备拉取或者客户端APP同步的方式进行数据更新并且有ACK应答机制，解决了本地ACL权限数据与云端权限数据的一致性问题。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图，而并不超出本申请要求保护的范围。

图1是根据本申请的一种物联网通信系统的示意图。

图2是根据本申请实施例的确定Matter设备本地访问控制权限的系统的示意图。

图3是根据本申请实施例的确定Matter设备本地访问控制权限的方法的流程图。

图4是本申请实施例提供的一种电子设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1是根据本申请的一种物联网通信系统的示意图。图1包括两种云生态系统，其中虚线界定的是本地或内部云生态系统，虚线外是第三方的云生态系统。如图1所示，内部云生态系统可以是涂鸦的云生态系统，其包括云端、客户端、路由器、网关/Hub、WiFi设备、蓝牙设备、zigbee设备和thread设备，其中客户端可以是手机、平板电脑等终端设备，其运行有App(Application，应用程序)，用于WiFi设备、蓝牙设备、zigbee设备thread设备等设备的上云以及与云端的交互，包括添加、删除设备等；路由器提供上网通道，网关/Hub用于协议转换和设备管理，包括添加、删除设备、设备在线离线的管理等。Matter协议能够支持Wifi协议和thread协议，Wifi设备和thread设备能够直接通过Matter协议进行上云等操作，其中，对于Wifi设备，可以通过路由器直接上云；对于thread设备，通过路由器和网关进行上云，其不需要网关进行协议转换，网关的作用是进行信息的透传；将能够支持Matter协议的设备简称为Matter设备；对于Matter协议不支持的协议，例如蓝牙、zigbee，蓝牙设备和zigbee设备在入网上云时，需要经过网关的协议转换，将不支持Matter协议的设备简称为非Matter设备。

图1中示出了该内部云生态系统的各个组成部分或设备之间的连接关系或数据传输关系以及该内部云生态系统与第三方云生态系统的云端、WiFi设备和thread设备的连接关系，其中，在该内部云生态系统不与第三方云生态系统之间发生关联时，云端与设备之间以及设备与设备之间可以按照内部协议(例如，对于涂鸦的内部云生态系统来说，内部协议就是涂鸦自定义的协议)进行通信和数据的处理；在该内部云生态系统与第三方云生态系统之间发生关联时，需要通过Matter协议实现两个云生态系统之间的互联互通。

在图1中，对于内部云生态系统的客户端控制第三方Matter设备(包括WiFi设备和thread设备)，根据一个实施例，客户端可以经由云端、路由器和网关实现对第三方Matter设备的控制；根据另一个实施例，客户端可以经由路由器和网关实现对第三方Matter设备的控制。在客户端控制第三方Matter设备的过程中，采用Matter协议实现了两个云生态系统之间的互通互联，使得内部云生态系统的客户端能够控制第三方Matter设备。类似地或相应地，第三方云生态系统的客户端也可以通过Matter协议实现对内部云生态系统的Matter设备的控制。

在图1中，对于非Matter设备(包括蓝牙设备和zigbee设备)，为了获得其他云生态系统的控制，需要通过网关映射到Matter网关上。

本申请是图1所示的系统中，在云端确定Matter设备的访问控制权限的方案。图2是根据本申请实施例的确定Matter设备本地访问控制权限的系统的示意图。如图2所示，该系统包括Matter设备、客户端和云端服务器，其中，Matter设备的数量可以为一个或多个。在一个实施例中，将家庭作为fabric的载体时，用户下的家庭在配置第一个Matter设备时，会为此家庭创建一对一的fabric，为后续在fabric里配置Matter设备做好前置准备。

在Matter设备激活阶段，云端服务器为此Matter设备分配nodeID，作为本地区域网里设备在fabric里的唯一标识。nodeID都通过云端分配，解决了本地nodeID生成重复的问题并且云端会维护在fabric下Matter设备与自身nodeID的关联关系。根据一些具体实施例，在Matter设备激活阶段，同时为当前配网的用户分配进行访问控制的唯一标识，其中，唯一标识包括UUID(Universally Unique Identifier，通用唯一标识符)字段或者其他将该Matter设备与其他设备进行区分的字段，例如MAC地址，预先设置的序列号等，为了简单起见，以下简称nodeID。云端也会维护在fabric下用户与对应访问控制nodeID的关联关系，然后为此访问控制nodeID生成权限等级为例如administer的权限控制列表项并写入到Matter设备的ACL里，云端此时会标记此权限已同步到设备内部。也就是说，当用户配网激活了一个Matter设备，此时由于云端嵌入式客户端三端约定激活时默认写入当前用户的nodeID和控制权限等级到Matter设备里，此时云端将默认记录当前用户为已同步状态，不用向Matter设备同步当前用户的ACL的更新。

Matter作为局域网协议，可以支持多个APP对同一个Matter设备激活配网。每个APP添加了Matter设备后，都会新建1个fabric，Matter设备可以添加的fabric的数量为5～254；这么多的fabric添加到Matter设备上，容易产生一个问题：难以清楚Matter设备被哪些APP配置了。

在一些实施例中，可以根据Matter设备添加的fabric中保护的vendorID字段识别添加方，通过vendorID字段例如可以表明被哪些厂商(例如华为、小米或涂鸦等)配置。这样，在APP客户端或Matter设备上或同账户下的带屏幕网关上展示所有的配网者fabric，给用户提供查看、编辑和删除的入口，例如，可以对于不同的APP设置不同的权限，删除某一个或某几个APP的配置等，方便对Matter设备的管理。

除了用户通过配网激活Matter设备时写入用户的nodeID和控制权限等级，当将Matter设备分享到其他用户时，被分享用户也可以将其nodeID和控制权限等级通过云端与Matter设备同步。其中，对于分享功能，可以是fabric(例如家庭)的分享，也可以是fabric下某个或某几个Matter设备的分享。在fabric分享后，被分享的用户可以获知该fabric下所有Matter设备的信息，例如Matter设备的nodeID等。

对于被分享用户的nodeID和控制权限等级的同步，具体来说，家庭有可能存在分享给其他用户的功能，此时其他用户就拥有了此家庭下所有设备的控制权限，Matter设备也不例外，所以此种场景下，在Matter设备激活上云时，云端查询当前家庭下有哪些被分享用户，然后为每个被分享用户在此家庭的fabric下生成唯一的对应访问控制nodeID，维护分享用户与对应访问控制nodeID的关联关系，然后云端为Matter设备生成相应的控制权限等级(例如为administer)的可访问控制nodeID的权限控制列表项。云端此时会标记权限未同步，这是因为云端只是记载了被分享用户的nodeID和对Matter设备的控制权限等级，这些信息没有与Matter设备同步，在与Matter设备同步后，被分享用户才能实现对于Matter设备的控制。

在一些实施例中，云端为不同用户生成的控制权限等级可以是相同的，也可以是不同的。例如，云端可以为所有用户均分配表1所示的Administer权限等级，也可以为不同用户分配表1所示的五个权限等级中的任意一个，本申请对此不作任何限制。

对于Matter设备的不同设备类型，系统采用不同的Matter设备同步方式。

在Matter设备与云端采用相同的内部协议，例如云端采用涂鸦云，Matter设备为涂鸦设备，二者均采用涂鸦制定的协议时，在客户端APP首页里会到云端拉取Matter设备的ACL权限同步状态信息，对于分享用户的客户端来说，其在拉取Matter设备的ACL权限同步状态信息的过程中，知道自己对Matter设备有控制权限，但是Matter设备仍然有未同步状态信息，从而能够发现相关的Matter设备有权限未同步完成；对于被分享用户的客户端来说，其在拉取Matter设备的ACL权限同步状态信息的过程中，知道自己对Matter设备没有控制权限，从而也能够发现相关的Matter设备有权限未同步完成。在发现相关的Matter设备有权限未同步完成时，客户端APP会直接发送消息(例如MQTT消息)给Matter设备，Matter设备收到消息后，主动到云端调用ACL权限接口进行数据同步，同步完成后，Matter设备会调用云端的ACK应答接口告知云端设备已同步完成，此时云端将之前未同步的权限状态修改成已同步。在这种情况下，分享用户的客户端和被分享用户的客户端均能够完成上述流程。

在Matter设备与云端采用不同的协议，例如云端采用涂鸦云，采用涂鸦制定的协议，而Matter设备为不采用涂鸦制定的协议的第三方设备时，在客户端APP首页里会到云端拉取Matter设备的ACL权限同步状态信息，对于分享用户的客户端来说，其在拉取Matter设备的ACL权限同步状态信息的过程中，知道自己对Matter设备有控制权限，但是Matter设备仍然有未同步状态信息，从而能够发现相关的Matter设备有权限未同步完成；对于被分享用户的客户端来说，其在拉取Matter设备的ACL权限同步状态信息的过程中，知道自己对Matter设备没有控制权限，从而也能够发现相关的Matter设备有权限未同步完成。在相关的Matter设备有权限未同步完成时，分享用户的客户端APP通过文案和未同步图标提示用户设备未同步，让分享用户使用客户端APP调用云端的ACL权限同步接口，分享用户的客户端APP例如通过本地局域网将权限数据(包括被分享用户的唯一标识和控制权限等级)同步到第三方Matter设备。同步完成后，客户端APP会调用云端的ACK应答接口告知云端设备已同步完成，此时云端将之前未同步的权限状态修改成已同步。对于被分享用户的客户端APP来说，在相关的Matter设备有权限未同步完成时，被分享用户的客户端APP通过文案和未同步图标提示用户设备未同步，但是因为被分享用户目前还没有对Matter设备的控制权限，其不能通过本地局域网将权限数据同步到三方Matter设备，所以，被分享用户的客户端APP会通过文案和未同步图标提示其目前没有权限执行对Matter设备的权限同步，并且提示用户通过其他有权限的用户完成Matter设备的权限同步，例如提示通过分享用户的客户端APP完成Matter设备的权限同步。

同步完成后，客户端APP会调用云端的ACK应答接口告知云端设备已同步完成，此时云端将之前未同步的权限状态修改成已同步。

分享用户在将Matter设备分享完成之后，还可以取消对该Matter设备的分享。在一个实施例中，分享用户的客户端向云端发送取消Matter设备分享的请求，云端在确认分享用户具有取消分享的权限后，删除被分享用户对应的唯一标识和控制权限等级，并标记未同步删除状态。分享用户的客户端或者被分享用户的客户端首页里会到云端拉取Matter设备的ACL权限状态信息，将删除被分享用户对应的唯一标识和控制权限等级的消息发送至Matter设备，Matter设备删除被分享用户对应的唯一标识和控制权限等级的记录，并调用云端的ACK应答接口告知云端Matter完成对本分享用户权限的删除，此时云端将之前的未同步删除状态修改成已同步删除状态。

Matter设备的ACL会记录具有控制权限的用户的唯一标识及其控制权限等级。对于Matter子设备来说，其不直接跟云端进行交互，而是通过与云端交互的中间设备(例如网关设备)进行交互进而间接到云端。对于Matter子设备的ACL，其不仅记录具有控制权限的用户的唯一标识及其控制权限等级，还会记录中间设备的唯一标识。

在图2所示的系统的基础上，根据本申请的一个方面，提供一种确定Matter设备本地访问控制权限的方法。图3是根据本申请实施例的确定Matter设备本地访问控制权限的方法的流程图。如图3所示，该方法包括如下步骤。

步骤S301，为用户配备在当前fabric下的唯一标识。

根据一些实施例，在用户通过配网激活Matter设备时，云端为所示用户配备当前fabric下的唯一标识。根据另一些实施例，当将Matter设备分享到其他用户时，在Matter设备激活上云时，云端查询当前家庭下有哪些被分享用户，然后为每个被分享用户在此家庭的fabric下生成唯一标识，例如唯一的对应访问控制nodeID，维护被分享用户与对应访问控制nodeID的关联关系。

通过云端用户配备在当前fabric下的唯一标识，使得每个用户在当前的fabric里拥有访问控制的唯一标识，解决了不同用户对于相同设备的控制问题，并且安全性得到的有效保证；并且，云端为用户分配访问控制的唯一标识，不仅有效解决了唯一标识本地分配时带来的重复问题，而且，由于云端是针对每个用户的账号进行唯一标识的分配，每个用户在不同的客户端设备上登录账号后，就能同步当前账号下的数据，解决多客户端的数据同步问题。

步骤S302，针对所述fabric下的Matter设备，为所述用户确定控制权限等级。

对于Matter设备的配网用户和被分享用户，云端为每个用户在当前fabric中的Matter设备确定控制权限等级。在一些实施例中，云端为不同用户生成的控制权限等级可以是相同的，也可以是不同的。例如，云端可以为所有用户均分配表1所示的Administer权限等级，也可以为不同用户分配表1所示的五个权限等级中的任意一个，本申请对此不作任何限制。

步骤S303，将所述唯一标识和所述控制权限等级分享至所述Matter设备，与所述Matter设备进行同步。

在一些实施例中，在Matter设备激活阶段，云端服务器为当前配网的用户分配进行访问控制的唯一标识，云端也会维护在fabric下用户与唯一标识的关联关系，然后为此唯一标识生成权限等级为例如administer的权限控制列表项并写入到Matter设备的ACL里，云端此时会标记此权限已同步到设备内部。也就是说，当用户配网激活了一个Matter设备，此时由于云端嵌入式客户端三端约定激活时默认写入当前用户的nodeID和控制权限等级到Matter设备里，此时云端将默认记录当前用户为已同步状态，不用向Matter设备同步当前用户的ACL的更新。

从而，步骤S303包括：在所述Matter设备激活配网的过程中，将所述唯一标识和所述控制权限等级写入所述Matter设备的访问控制列表。

在另一些实施例中，当将Matter设备分享到其他用户时，被分享用户也可以将其nodeID和控制权限等级通过云端与Matter设备同步。具体来说，家庭有可能存在分享给其他用户的功能，此时其他用户就拥有了此家庭下所有设备的控制权限，Matter设备也不例外，所以此种场景下，在Matter设备激活上云时，云端查询当前家庭下有哪些被分享用户，然后为每个被分享用户在此家庭的fabric下生成唯一的对应访问控制nodeID，维护分享用户与对应访问控制nodeID的关联关系，然后云端为Matter设备生成相应的控制权限等级(例如为administer)的可访问控制nodeID的权限控制列表项。云端此时会标记权限未同步，这是因为云端只是记载了被分享用户的nodeID和对Matter设备的控制权限等级，这些信息没有与Matter设备同步，在与Matter设备同步后，被分享用户才能实现对于Matter设备的控制。

对于Matter设备的不同设备类型，系统采用不同的Matter设备同步方式。

根据一些实施例，在Matter设备与云端采用相同的内部协议，例如云端采用涂鸦云，Matter设备为涂鸦设备，二者均采用涂鸦制定的协议时，在客户端APP首页里会到云端拉取Matter设备的ACL权限同步状态信息，对于分享用户的客户端来说，其在拉取Matter设备的ACL权限同步状态信息的过程中，知道自己对Matter设备有控制权限，但是Matter设备仍然有未同步状态信息，从而能够发现相关的Matter设备有权限未同步完成；对于被分享用户的客户端来说，其在拉取Matter设备的ACL权限同步状态信息的过程中，知道自己对Matter设备没有控制权限，从而也能够发现相关的Matter设备有权限未同步完成。在发现相关的Matter设备有权限未同步完成时，客户端APP会直接发送消息(例如MQTT消息)给Matter设备，Matter设备收到消息后，向云端发送访问控制权限同步请求，主动到云端调用ACL权限接口进行数据同步，同步完成后，Matter设备会调用云端的ACK应答接口告知云端设备已同步完成，此时云端将之前未同步的权限状态修改成已同步。在这种情况下，分享用户的客户端和被分享用户的客户端均能够完成上述流程。

这样，步骤S303包括：响应于所述Matter设备的访问控制权限同步请求，向所述Matter设备发送所述唯一标识和所述控制权限等级。

根据另一些实施例，在Matter设备与云端采用不同的协议，例如云端采用涂鸦云，采用涂鸦制定的协议，而Matter设备为不采用涂鸦制定的协议的第三方设备时，在客户端APP首页里会到云端拉取Matter设备的ACL权限同步状态信息，对于分享用户的客户端来说，其在拉取Matter设备的ACL权限同步状态信息的过程中，知道自己对Matter设备有控制权限，但是Matter设备仍然有未同步状态信息，从而能够发现相关的Matter设备有权限未同步完成；对于被分享用户的客户端来说，其在拉取Matter设备的ACL权限同步状态信息的过程中，知道自己对Matter设备没有控制权限，从而也能够发现相关的Matter设备有权限未同步完成。在相关的Matter设备有权限未同步完成时，分享用户的客户端APP通过文案和未同步图标提示用户设备未同步，让分享用户使用客户端APP调用云端的ACL权限同步接口，获得被分享用户的唯一标识和控制权限等级，分享用户的客户端APP例如通过本地局域网将权限数据(包括被分享用户的唯一标识和控制权限等级)同步到第三方Matter设备。同步完成后，分享用户的客户端APP会调用云端的ACK应答接口告知云端设备已同步完成，此时云端将之前未同步的权限状态修改成已同步。对于被分享用户的客户端APP来说，在相关的Matter设备有权限未同步完成时，被分享用户的客户端APP通过文案和未同步图标提示用户设备未同步，但是因为被分享用户目前还没有对Matter设备的控制权限，其不能通过本地局域网将权限数据同步到三方Matter设备，所以，被分享用户的客户端APP会通过文案和未同步图标提示其目前没有权限执行对Matter设备的权限同步，并且提示用户通过其他有权限的用户完成Matter设备的权限同步，例如提示通过分享用户的客户端APP完成Matter设备的权限同步。同步完成后，客户端APP会调用云端的ACK应答接口告知云端设备已同步完成，此时云端将之前未同步的权限状态修改成已同步。

这样，步骤S303包括：在所述用户为被分享用户的情况下，响应于分享用户的客户端的数据同步请求，向所述客户端发送所述唯一标识和所述控制权限等级，使得所述客户端能够将所述唯一标识和所述控制权限等级与所述Matter设备进行同步。

如上所述，对于与云端采用相同的内部协议的Matter设备，同步完成后，Matter设备会调用云端的ACK应答接口告知云端设备已同步完成，此时云端将之前未同步的权限状态修改成已同步；对于第三方设备，同步完成后，客户端APP会调用云端的ACK应答接口告知云端设备已同步完成，此时云端将之前未同步的权限状态修改成已同步。

这样，图3所示的方法还包括：获得所述唯一标识和所述控制权限等级同步完成的消息。

在一些实施例中，分享用户在将Matter设备分享完成之后，还可以取消对该Matter设备的分享。在一个实施例中，分享用户的客户端向云端发送取消Matter设备分享的请求，云端在确认分享用户具有取消分享的权限后，删除被分享用户对应的唯一标识和控制权限等级，并标记未同步删除状态。分享用户的客户端或者被分享用户的客户端首页里会到云端拉取Matter设备的ACL权限状态信息，将删除被分享用户对应的唯一标识和控制权限等级的消息发送至Matter设备，Matter设备删除被分享用户对应的唯一标识和控制权限等级的记录，并调用云端的ACK应答接口告知云端Matter完成对本分享用户权限的删除，此时云端将之前的未同步删除状态修改成已同步删除状态。

这样，图3所示的方法还包括：响应于分享用户的客户端的取消所述Matter设备分享的请求，删除被分享用户对应的唯一标识和控制权限等级。

根据本申请提供的确定Matter设备本地访问控制权限的方法和系统，首先，使得每个用户在当前的fabric里拥有访问控制的唯一标识，解决了不同用户对于相同设备的控制问题，并且安全性得到的有效保证；其次，云端分配了Matter设备自身的唯一标识以及为用户分配访问控制的唯一标识，不仅有效解决了唯一标识本地分配时带来的重复问题，而且，由于云端是针对每个用户的账号进行唯一标识的分配，解决多客户端的数据同步问题；另外，Matter设备的ACL权限进行云端管理，通过Matter设备拉取或者客户端APP同步的方式进行数据更新并且有ACK应答机制，解决了本地ACL权限数据与云端权限数据的一致性问题。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

参阅图4，图4提供一种电子设备，包括处理器以及存储器。存储器存储有计算机指令，当计算机指令被处理器执行时，使得处理器执行所述计算机指令从而实现如图3所示的方法以及细化方案。

应该理解，上述的装置实施例仅是示意性的，本发明披露的装置还可通过其它的方式实现。例如，上述实施例中所述单元/模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如，多个单元、模块或组件可以结合，或者可以集成到另一个系统，或一些特征可以忽略或不执行。

另外，若无特别说明，在本发明各个实施例中的各功能单元/模块可以集成在一个单元/模块中，也可以是各个单元/模块单独物理存在，也可以两个以上单元/模块集成在一起。上述集成的单元/模块既可以采用硬件的形式实现，也可以采用软件程序模块的形式实现。

所述集成的单元/模块如果以硬件的形式实现时，该硬件可以是数字电路，模拟电路等等。硬件结构的物理实现包括但不局限于晶体管，忆阻器等等。若无特别说明，所述处理器或芯片可以是任何适当的硬件处理器，比如CPU、GPU、FPGA、DSP和ASIC等等。若无特别说明，所述片上缓存、片外内存、存储器可以是任何适当的磁存储介质或者磁光存储介质，比如，阻变式存储器RRAM(Resistive Random Access Memory)、动态随机存取存储器DRAM(Dynamic Random Access Memory)、静态随机存取存储器SRAM(Static Random-AccessMemory)、增强动态随机存取存储器EDRAM(Enhanced Dynamic Random Access Memory)、高带宽内存HBM(High-Bandwidth Memory)、混合存储立方HMC(Hybrid Memory Cube)等等。

所述集成的单元/模块如果以软件程序模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本披露各个实施例所述方法的全部或部分步骤。而前述的存储器包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例还提供一种非瞬时性计算机存储介质，存储有计算机程序，当所述计算机程序被多个处理器执行时，使得所述处理器执行如图3所示的方法以及细化方案。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本申请所必须的。

以上对本申请实施例进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明仅用于帮助理解本申请的方法及其核心思想。同时，本领域技术人员依据本申请的思想，基于本申请的具体实施方式及应用范围上做出的改变或变形之处，都属于本申请保护的范围。综上所述，本说明书内容不应理解为对本申请的限制。