CN113312664B - 用户数据授权方法及用户数据授权系统 - Google Patents

Abstract

本说明书一个或多个实施例提供一种用户数据授权方法及用户数据授权系统；该方法可以包括：客户端可以基于用户的身份私钥和分布式数字身份信息、该客户端中的目标应用的分布式数字身份信息颁发可验证声明，该可验证声明用于指示允许目标应用获取用户的用户数据；以及，客户端可以通过目标应用的身份私钥对可验证声明进行签名，并将签名后的可验证声明添加至数据获取请求中，以发送至数据提供方；数据提供方在接收到数据获取请求后，即可基于可验证声明所含的被授权方的分布式数字身份信息获取被授权方的身份公钥，以用于对可验证声明进行验签，并在验签通过的情况下，将可验证声明中指示的用户数据返回至客户端，以提供至目标应用。

Description

用户数据授权方法及用户数据授权系统

技术领域

本说明书一个或多个实施例涉及终端技术领域，尤其涉及一种用户数据授权方法及用户数据授权系统。

背景技术

在相关技术中，若客户端中的应用需要获取用户数据，只需该客户端所对应的认证方对用户的身份进行认证即可，数据提供方听从认证方的认证结果，向相应应用返回其所请求获取的用户数据。不难看出，相关技术在获取用户数据的过程中，用户无法对数据提供方返回的用户数据的范围进行控制。

发明内容

有鉴于此，本说明书一个或多个实施例提供一种用户数据授权方法及用户数据授权系统。

本说明书一个或多个实施例提供技术方案如下：

根据本说明书一个或多个实施例的第一方面，提出了一种用户数据授权方法，包括：

客户端在接收到用户的授权指示的情况下，基于所述用户的身份私钥、所述用户的分布式数字身份信息和所述客户端中的目标应用的分布式数字身份信息颁发可验证声明，所述可验证声明用于指示允许所述目标应用获取所述用户的用户数据；以及，所述客户端向数据提供方发送包含所述可验证声明的数据获取请求，且所述数据获取请求或所述数据获取请求中包含的可验证声明由所述目标应用的身份私钥进行签名；

数据提供方从接收到的所述数据获取请求中读取可验证声明，并根据读取到的可验证声明中所含被授权方的分布式数字身份信息从区块链系统处获取相应的身份公钥，以通过获取到的身份公钥对接收到的数据获取请求或读取的可验证声明进行验签，并在验签成功的情况下，将读取的可验证声明中指示的用户数据返回所述客户端以提供至所述目标应用。

根据本说明书一个或多个实施例的第二方面，提出了一种用户数据授权系统，包括：客户端和数据提供方；其中，

所述客户端在接收到用户的授权指示的情况下，基于所述用户的身份私钥、所述用户的分布式数字身份信息和所述客户端中的目标应用的分布式数字身份信息颁发可验证声明，所述可验证声明用于指示允许所述目标应用获取所述用户的用户数据；以及，所述客户端向所述数据提供方发送包含所述可验证声明的数据获取请求，且所述数据获取请求或所述数据获取请求中包含的可验证声明由所述目标应用的身份私钥进行签名；

所述数据提供方从接收到的所述数据获取请求中读取可验证声明，并根据读取到的可验证声明中所含被授权方的分布式数字身份信息从区块链系统处获取相应的身份公钥，以通过获取到的身份公钥对接收到的数据获取请求或读取的可验证声明进行验签，并在验签成功的情况下，将读取的可验证声明中指示的用户数据返回所述客户端以提供至所述目标应用。

附图说明

图1是一示例性实施例提供的一种用户数据授权方法的流程图。

图2是一示例性实施例提供的一种用户数据授权系统的示意图。

图3是一示例性实施例提供的一种用户登录方法的交互图。

图4是一示例性实施例提供的一种用户数据授权方法的交互图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

在相关技术中，若客户端中的应用需要获取用户的用户数据时，只需客户端所对应的认证方完成针对用户的认证，即可指示相应的数据提供方向将用户的用户数据提供至上述应用。

应当理解的是，相关技术中的数据提供方相当于听从认证方的认证结果向应用返回用户数据，这使得用户无法对数据提供方为应用提供用户数据的操作进行控制，进而导致数据提供方向应用提供用户数据时，仅存在提供或不提供的区分，而无法对所提供的用户数据的范围进行控制。除此之外，由于数据提供方直接听从授权方的认证结果进行授权，不存在任何授权凭证，导致数据提供方在后续追溯过程中，无法对上述授权过程进行自证。

为解决上述问题，本说明书提出了一种用户数据授权方法，使得用户能够控制数据提供方向应用开放的用户数据的授权范围，避免了相关技术中无法对用户数据的授权范围进行控制的问题。

图1是本说明书一示例性实施例示出的一种用户数据授权方法的流程图。该方法可以包括以下步骤：

步骤102，客户端在接收到用户的授权指示的情况下，基于所述用户的身份私钥、所述用户的分布式数字身份信息和所述客户端中的目标应用的分布式数字身份信息颁发可验证声明，所述可验证声明用于指示允许所述目标应用获取所述用户的用户数据；以及，所述客户端向数据提供方发送包含所述可验证声明的数据获取请求，且所述数据获取请求或所述数据获取请求中包含的可验证声明由所述目标应用的身份私钥进行签名。

鉴于相关技术中的技术问题是由于数据提供方听从认证方的认证结果，向应用提供用户数据而导致的，本公开不再依赖于上述认证方的认证结果进行用户数据授权，而是通过由用户向请求获取用户数据的应用发放VC(Verifiable Claim，可验证声明)的方式，指示数据提供方对该应用进行用户数据授权。其中，在该VC中可以包含授权方、被授权方、以及授权内容等信息。具体的，在本说明书发放的VC中，该授权方即为客户端所对应的用户，被授权方即为请求获取用户数据的应用，而授权内容则可以包括授权的用户数据中的范围。

应当理解的是，由于本说明书通过发放VC的方式指示数据提供方进行用户数据授权，使得本说明书中的用户可以对自身数据的授权范围等内容进行控制，避免了相关技术中用户对数据授权操作不可控，而导致用户数据授权范围过大，进而造成信息泄露过多的问题。其次，由于数据提供方基于VC进行用户数据授权，使得在后续追溯过程中，可以通过VC向追溯方证明：自身是基于用户的指示向相应的应用开放获取用户数据的权限。换言之，通过本说明书的技术方案使得数据提供方能够在后续追溯过程中，对数据授权操作进行自证。

需要声明的是，VC需要基于DID(Decentralized Identifiers,分布式数字身份)颁发，而DID注册于区块链系统中，可见，本说明书相当于依托于区块链系统这一分布式架构进行用户数据授权，避免了相关技术中依托于中心化服务而导致的问题。在实际操作中，可以预先在区块链系统中注册上述用户、客户端、应用等的DID，以用于颁发VC和验证VC。具体的，在为任一对象注册DID时，可以基于该任一对象的描述信息和身份公钥生成相应的注册交易，并将生成的注册交易发送至区块链系统；区块链系统即可执行接收到的注册交易，以生成与该任一对象对应的DID和DID文档，并将注册交易中包含的身份公钥、描述信息等维护于该DID文档中。在此基础上，任一设备在需要对该任一对象进行身份认证时，只需提供该任一对象的DID，即可从区块链系统中获取该任一对象的身份公钥，以基于该身份公钥对通过该任一对象的身份私钥进行签名后的签名信息进行验签，进而完成针对该任一对象的身份认证。

在本说明书中，客户端在接收到目标应用发起的用户数据授权请求之后，即可将该用户数据授权请求传达给用户，以便用户确定是否向目标应用开放相应数据的获取权限。其中，客户端在接收到用户的授权指示后，还可以进一步判断该用户是否已经处于登录状态，若已处于登录状态，则基于用户的身份私钥、用户的分布式数字身份信息以及客户端中的目标应用的分布式数字身份信息颁发上述可验证声明；否则，不颁发该可验证声明。

在该前提下，为了使客户端可以在获得用户授权的情况下，正常执行颁发可验证声明的操作，本说明书还可以包括用户在客户端上进行登录的步骤：

在一实施例中，用户可以通过相关技术中方式，即基于中心化服务进行登录。具体的，客户端可以向用户展示登录界面，以便用户输入相应的用户认证信息，如账号、密码等；在此基础上，客户端即可基于用户认证信息生成相应的认证请求，并发送至该客户端所对应的认证方处，认证方在对用户认证信息进行验证后，即可向客户端返回登录授权信息，以指示客户端将用户的登录状态标记为已登录。

在另一实施例中，用户可以通过自身预先注册于区块链系统中的DID进行登录。具体的，客户端可以在接收到用户的登录请求的情况下，基于用户的身份私钥以及DID，向客户端所对应的认证方发起登录请求；而认证方在接收到该登录请求后，即可基于其中包含的DID从区块链系统处获取用户的身份公钥，以对登录请求进行验签，并在验签通过的情况下，向客户端返回登录授权信息；客户端在接收到登录授权信息后，即可将用户的登录状态标记为已登录。

应当理解的是，若通过账号、密码等用户认证信息进行登录，其本质上是将用户输入的认证信息与中心化服务器中预先注册的认证信息进行比对，以确定用户是否登录成功。而中心化服务器中存储的数据受服务提供方控制，极易被篡改，而导致整个登录过程不可靠。而在本实施例中，将用户预先注册于区块链系统中的DID作为登录凭证，而DID由于注册于区块链系统中(相当于登录凭证具有区块链系统的背书)，本身具有不可篡改的特性，致使本实施例相较于通过中心化服务进行登录的方式，更具可靠性。

在本说明书中，将请求获取用户数据的应用命名为目标应用。在实际应用中，该目标应用既可以为客户端的原生服务方提供的原生应用，也可以为区别于该原生服务方的第三方服务方提供的第三方应用。其中，在目标应用为第三方应用时，该第三方应用可以为运行于客户端中的小程序、H5页面等。

举例而言，在客户端为即时通讯客户端时，若上述目标应用为上述原生应用，该目标应用可以为运行于该即时通讯客户端的即时通讯应用；若上述目标应用为上述第三方应用，该目标应用可以为运行于该即时通讯客户端上的、由某一购物平台服务方提供的购物应用(如可以以小程序、或H5页面的形式呈现)。当然，该举例仅是示意性的，上述目标应用和第三方应用具体为何种应用可以由本领域技术人员根据实际情况确定。

在本说明书中，目标应用可以通过客户端向用户发起数据授权请求，例如，可以通过在界面中展示该数据授权请求，或者通过播报该数据授权请求的方式，告知用户：目标应用请求获取用户数据；而用户则可以响应该数据授权请求，以向客户端发送针对该目标应用的授权指示。在此基础上，客户端即可基于用户的身份私钥、用户的DID，以及目标应用的DID颁发VC，该VC用于指示允许目标应用获取用户的用户数据；在完成VC颁发后，客户端即可进一步向数据提供方发送包含该VC的数据获取请求，且该数据获取请求或该数据获取请求中包含的VC由目标应用的身份私钥进行签名。

步骤104，数据提供方从接收到的所述数据获取请求中读取可验证声明，并根据读取到的可验证声明中所含被授权方的分布式数字身份信息从区块链系统处获取相应的身份公钥，以通过获取到的身份公钥对接收到的数据获取请求或读取的可验证声明进行验签，并在验签成功的情况下，将读取的可验证声明中指示的用户数据返回所述客户端以提供至所述目标应用。

在本说明书中，当数据提供方接收到上述数据获取请求后，即可从中读取VC，并根据VC中包含的被授权方的DID从区块链系统中获取被授权方的身份公钥，以通过该身份公钥对数据获取请求或VC进行验签。若验签成功，则证明目标应用即为VC中的被颁发方，可以将VC中指示的用户数据返回至客户端，以提供至目标应用。

需要声明的是，尽管相关技术在对VC进行验证时，需要对VC中包含的授权方、被授权方均进行验证，而在本说明书中则只需对被授权方进行验证即可。原因在于：VC必然需要基于区块链系统中注册的DID进行颁发，本身具有可靠性，因此无需验证VC是否可信；且本说明书关注的重点为“目标应用是否获得了用户数据授权”，但并不关注“该权限由谁授予”。换言之，本说明书的VC中包含的授权方既可以是上述用户自身，也可以是其他具有对该用户的用户数据进行授权的其他对象。因此，在本说明书中，用户在颁发VC时，只需通过目标应用的身份私钥进行验签；相应的，数据提供方在验证VC时，则只需基于被授权方的身份公钥对VC进行验签，即可确定目标应用是否有权限获取相应的用户数据。

应当理解的是，尽管本说明书可以仅对VC中的被授权方进行验证，但在实际应用中，也可以如相关技术，对VC中的授权方也进行验证，且仅在授权方和被授权方均验证通过的情况下，再将VC中指示的用户数据返回至客户端。具体的，用户颁发的VC在经由目标应用的身份私钥签名的同时，可以进一步经由用户的身份私钥进行签名；在此基础上，数据提供方在接收到VC之后，即可根据VC中包含的授权方的DID从区块链系统处获取授权方的身份公钥，以基于该身份公钥对VC进行验签，若验签成功，则证明VC中的授权方为该用户。在该实施例中，数据提供方仅在基于授权方的身份公钥执行的验签操作、以及基于被授权方的身份公钥执行的验签操作均通过的情况下，才将相应的用户数据返回至客户端。

上述对VC中的授权方和被授权方均进行验证的方法，相当于严格了目标应用获取用户数据授权的标准，即仅在确定是由用户本身授予目标应用获取其用户数据的权限的情况下，数据提供方才将VC中指示的用户数据提供至目标应用。

在实际应用中，颁发的VC存在一定的时效性，VC是否有效既可以根据预先设定的有效时间确定，也可以根据用户的指示进行变更。对此，可由本领域技术人员根据实际需求确定，本公开对此不作限制。

在本说明书中，可以通过将VC注册至区块链系统的方式，维护VC的状态信息，以便数据提供方在接收到VC的情况下，通过区块链系统中维护的状态信息确定VC的有效性。其中，数据提供方唯有在确定区块链系统中维护的状态信息表明该VC有效、且针对可验证声明的验签成功的情况下，将VC中指示的用户数据返回至客户端。

在实际应用中，数据提供方可以通过多种方式获取VC的状态信息，例如，客户端在用户完成VC颁发之后，可以生成相应的注册交易，并发送至区块链系统，以由区块链系统生成对应于该VC的DID，并对该VC的DID和状态信息进行关联存储，在此基础上，数据提供方在接收到VC之后，即可将VC的DID提供至区块链系统，以由区块链系统根据该DID获取VC的状态信息并返回至数据提供方。当然，该举例仅是示意性的，具体如何获取VC的状态信息可由本领域技术人员根据实际需求确定，本说明书对此不作限制。

需要声明的是，尽管上述在区块链系统中注册VC的操作可由客户端和区块链系统直接交互完成。然而，在现今的大多数区块链架构中，通常仅允许与区块链技术提供方存在合作关系的服务方能够与区块链系统进行交互，而该服务方可以为上述负责对用户认证信息进行认证的认证方。因此，本说明书中的客户端在需要将VC注册至区块链系统时，可以生成针对该VC的注册请求，并将生成的注册请求发送至认证方；认证方接收到注册请求后，即可基于该注册请求中包含的VC，生成注册交易，并发送至区块链系统；区块链系统则可以通过执行该注册交易，以对交易中包含的VC进行存证并维护该VC的状态信息。

正如上文所述，VC是否有效可以根据用户的指示进行变更。相应的，在将VC注册至区块链系统之后，若用户需要将已注册的VC无效化，即可向客户端发送针对该已注册VC的吊销请求，客户端在接收到吊销请求后，可以指示区块链系统将该已注册VC的状态信息变更为吊销状态，以用于表征该VC已被上述用户无效化。

在本说明书中，上述数据提供方既可以为区块链系统，也可以为区别于区块链系统的数据服务器。

其中，在上述数据提供方为区别于区块链系统的数据服务器时，该数据服务器可以归属于某一数据网络。在该情况下，客户端可以优先将VC发送至该数据网络对应的中转服务器，以由该中转服务器根据用户的DID从数据网络包含的若干数据服务器中确定出存储有VC中指示的用户数据的数据服务器，并将该VC发送至确定出的数据服务器处。

而在上述数据提供方为区块链系统时，客户端可以基于VC生成相应的数据获取交易，并发送至区块链系统，以由区块链系统根据VC中包含的用户的DID或者用户数据的描述信息，从维护的链上数据中获取所需返回至客户端的用户数据。

当然，上述举例均是示意性的，具体如何从数据提供方处获取VC中所指示的用户数据，可由本领域技术人员根据实际情况确定，本说明书对此不作限制。

在本说明书中，VC中应当包含所需获取的用户数据的描述信息，以便数据提供方在接收到VC后，可以根据其中的描述信息获取存储的关于用户的第一数据，以作为需要返回至客户端的用户数据。

然而，在实际应用中，用户的用户数据中包含大量的隐私数据，这些数据通常不方便直接透露给目标应用，因此，若目标应用要求获取的数据包含隐私数据，用户在颁发VC时，还可以进一步在其中约束数据提供方在向目标应用提供用户数据时的形式。例如，可以规定：在根据VC中的描述信息获取到存储的关于用户的第二数据后，按照VC中的指示对该第二数据进行处理，并将处理结果作为需要返回至客户端的用户数据。例如，当目标应用需要确认用户是否成年时，其请求的用户数据可能为用户的年龄，此时，本公开中的数据提供方可以在VC的指示下，获取年龄信息之后，判断用户的年龄是否超过18，并根据判断结果向客户端返回“是否成年”的结论，以作为上述用户数据。应当理解的是，通过该方式可以避免用户的隐私数据被泄露，提高了用户数据的安全性。

为了进一步保证用户数据的安全性，在数据提供方获取到上述第二数据后，还可以进一步在TEE(Trusted execution environment，可信执行环境)中执行针对第二数据的处理操作。具体的，用户颁发的VC中还可以包含：需要对获取到的第二数据进行安全计算的指示，以及用于进行安全计算的TEE的指示信息。那么，数据提供方即可在获取到第二数据之后，基于VC中指示的TEE的身份公钥对获取到的第二数据进行加密，并传输至该TEE中，以由该TEE基于自身的身份私钥对加密后的第二数据进行解密后，按照VC中指示的预先部署的计算任务对第二数据执行安全计算。然后，数据提供方即可将该TEE生成的安全计算结果作为需返回至客户端的用户数据。

在实际应用中，上述TEE既可以部署于隐私区块链中，可以部署于链下隐私计算节点中。

其中，在部署于隐私区块链中时，上述TEE为链上TEE。数据提供方在获取到VC后，可以基于该VC中指示的链上TEE的身份公钥，对获取到的第二数据进行加密，并基于加密后的第二数据以及VC中所含的计算任务生成安全计算交易，该安全计算交易被发送至隐私区块链；隐私区块链在接收到该安全计算交易后，即可在自身维护的链上TEE中执行该安全计算交易，以在通过链上TEE的身份私钥对第二数据进行解密后，调用预先部署的用于完成上述计算任务的智能合约，对解密后的第二数据进行安全计算。

需要声明的是，该隐私区块链既可以为上述区块链系统，也可以为区别于上述区块链系统的其他区块链系统，具体如何部署该隐私区块链，可由本领域技术人员根据实际情况确定，本说明书对此不作限制。

当然，上述TEE无论部署于链上还是部署于链下，在完成安全计算后，可以优先通过目标应用的身份公钥对安全计算结果进行加密后，再将安全计算结果输出，并传输至客户端，以进一步保证用户数据的安全性。

其次，还需强调的是，本说明书中的区块链系统，既可以搭载于区块链技术的传统架构，即区块链系统中的所有节点均通过在相应实体设备上部署区块链代码而形成，大多数情况下，每个节点均对应于一个实体设备；本说明书的技术方案也可以搭载于区块链技术中的BaaS(Blockchain as a Service)架构，即区块链系统中的所有节点均通过云服务在云端实现的虚拟机上部署区块链代码而形成，区块链节点无需一一对应于相应的实体设备，在该架构中，还包括用于为各个区块链节点提供区块链即服务的BaaS平台(或称为BaaS云)，可以通过区块链上发生的活动(诸如订阅和通知、用户验证、数据库管理和远程更新)，提供预先编写的软件的方式，面向与BaaS平台连接的客户端侧计算设备，提供简单易用，一键部署，快速验证，灵活可定制的区块链服务，进而可以加速区块链业务应用开发、测试、上线，助力各行业区块链商业应用场景的落地。对应到本说明书中，即可通过BaaS平台实现VC的快速验签，以提高数据获取效率。

由上述技术方案可知，本说明书在需要向客户端中的应用提供用户数据时，会优先在用户的授意下，基于用户的身份私钥和分布式数字身份信息、以及该应用的分布式数字身份信息，颁发可验证声明。其中，该可验证声明用于指示允许上述应用获取上述用户的用户数据。在此基础上，客户端即可进一步向数据提供方发送包含该可验证声明的数据获取请求，且该数据获取请求或者可验证声明经由目标应用的身份私钥签名。相应的，数据提供方在接收到该数据获取请求后，可以根据可验证声明中包含的被授权方的分布式数字身份信息获取被授权方的身份公钥，以对可验证声明或者数据获取请求进行验签。

应当理解的是，本说明书中的数据提供方基于被授权方的身份公钥对可验证声明或者数据获取请求进行验签，相当于验证了可验证声明中的被授权方是否为请求获取用户数据的目标应用。显然，在验签通过的情况下，即可证明目标应用已经获取了获取可验证声明中指示的用户数据的权限。可见，本说明书是将可验证声明作为用户对目标应用进行用户数据授权的凭证，用户可以在该可验证声明中明确指示将哪些用户数据提供给上述应用，使得用户可以对用户数据的授权范围进行控制，避免了相关技术中由于采用中心化服务进行用户数据授权，而导致用户无法对用户数据的授权范围进行控制的问题；除此之外，由于可验证声明被发送至数据提供方，使得数据提供方可以在后续追溯过程中，向追溯方自证用户数据授权过程是在用户的指示下完成，避免了相关技术中由于缺乏授权凭证，而导致数据提供方无法对用户数据授权操作进行自证的问题。

进一步的，相关技术通过中心化服务进行登录，其认证方和数据提供方由同一服务方提供，数据提供方听从认证方的认证结果进行用户数据授权，即相关技术中的认证方和数据提供方相互绑定，无法解耦。而在本说明书中，数据提供方基于颁发的可验证声明向客户端返回用户数据，无需依赖于认证方的认证结果，可见，本说明书的技术方案实现了认证方与数据提供方的解耦，两者完全可以由不同的服务方提供，提高了该用户数据授权方法的适用性。

再进一步的，本说明书中的数据提供方在获取到可验证声明所指示的数据后，可以进一步对获取到的数据进行处理，并仅将处理结果返回至客户端，而不会将原始数据返回，避免了相关技术中用户隐私数据泄露的问题。

本说明书还提出了一种用户数据授权系统，以用于实现上述用户数据授权方法。需要声明的是，下一实施例中的大多操作方式，如，如何颁发可验证声明、如何对可验证声明进行验证、如何进行安全计算等，均与上一实施例相类似，具体操作方式均可参照上一实施例的介绍，在下文中不再赘述。

图2是本说明书一示例性实施例示出的一种用户数据授权系统的示意图。该系统可以包括：客户端21和数据提供方22；其中，

客户端21在接收到用户的授权指示的情况下，基于所述用户的身份私钥、所述用户的分布式数字身份信息和客户端21中的目标应用的分布式数字身份信息颁发可验证声明，所述可验证声明用于指示允许所述目标应用获取所述用户的用户数据；以及，客户端21向所述数据提供方发送包含所述可验证声明的数据获取请求，且所述数据获取请求或所述数据获取请求中包含的可验证声明由所述目标应用的身份私钥进行签名；

所述数据提供方22从接收到的所述数据获取请求中读取可验证声明，并根据读取到的可验证声明中所含被授权方的分布式数字身份信息从区块链系统处获取相应的身份公钥，以通过获取到的身份公钥对接收到的数据获取请求或读取的可验证声明进行验签，并在验签成功的情况下，将读取的可验证声明中指示的用户数据返回客户端21以提供至所述目标应用。

如上所述，在本说明书中，用户需要在客户端21中处于已登录的状态下，才会接收到应用的用户数据授权请求。因此，在本说明书中还可以包括用户在客户端21上登录的操作。在一实施例中，用户可以通过相关技术中方式，即基于中心化服务进行登录。在另一实施例中，用户可以通过自身预先注册于区块链系统中的DID进行登录。具体的，客户端21可以在接收到用户的登录请求的情况下，基于用户的身份私钥以及DID，向客户端21所对应的认证方发起登录请求；而认证方在接收到该登录请求后，即可基于其中包含的DID从区块链系统处获取用户的身份公钥，以对登录请求进行验签，并在验签通过的情况下，向客户端21返回登录授权信息；在此基础上，客户端21在接收到登录授权信息后，即可将用户的登录状态标记为已登录。

如上所述，本说明书将请求获取用户数据的应用命名为目标应用。其中，该目标应用既可以为客户端21的原生服务方提供的原生应用，也可以为区别于该原生服务方的第三方服务方提供的第三方应用。

如上所述，本说明书既可以仅对VC中的被授权方进行验证，也可以如相关技术中对VC中的授权方和被授权方均进行验证。

如上所述，颁发的VC存在一定的时效性，VC是否有效既可以根据预先设定的有效时间确定，也可以根据用户的指示进行变更。对此，可由本领域技术人员根据实际需求确定，本公开对此不作限制。具体的，本说明书可以通过将VC注册至区块链系统的方式，维护VC的状态信息，以便数据提供方22在接收到VC的情况下，通过区块链系统中维护的状态信息确定VC的有效性。其中，数据提供方22唯有在确定区块链系统中维护的状态信息表明该VC有效、且针对可验证声明的验签成功的情况下，将VC中指示的用户数据返回至客户端21。

如上所述，本说明书中的客户端21在需要将VC注册至区块链系统时，可以生成针对该VC的注册请求，并将生成的注册请求发送至认证方；认证方接收到注册请求后，即可基于该注册请求中包含的VC，生成注册交易，并发送至区块链系统；区块链系统则可以通过执行该注册交易，以对交易中包含的VC进行存证并维护该VC的状态信息。

如上所述，本说明书中的客户端21还可以在接收到用户发送的针对已注册VC的吊销请求的情况下，指示区块链系统将已注册VC的状态信息变更为吊销状态。

如上所述，本说明书中的数据提供方22既可以为区块链系统，也可以为区别于区块链系统的数据服务器。

如上所述，在数据提供方22归属于某一数据网络的情况下，客户端21可以优先将VC发送至该数据网络对应的中转服务器，以由该中转服务器根据用户的DID从数据网络包含的若干数据提供方22中确定出存储有VC中指示的用户数据的数据提供方22，并将该VC发送至确定出的数据提供方22处。

如上所述，在本说明书中，数据提供方22可以根据VC的指示获取存储的关于用户的第一数据，以作为需返回至客户端21的用户数据；或者，数据提供方22可以根据VC的指示获取存储的关于用户的第二数据，并按照VC的指示对该第二数据进行处理，以将处理结果作为需返回至客户端21的用户数据。

如上所述，为了进一步保证用户数据的安全性，在数据提供方22获取到上述第二数据后，还可以进一步在TEE中执行针对第二数据的处理操作。具体的，用户颁发的VC中还可以包含：需要对获取到的第二数据进行安全计算的指示，以及用于进行安全计算的TEE的指示信息。那么，数据提供方22即可在获取到第二数据之后，基于VC中指示的TEE的身份公钥对获取到的第二数据进行加密，并传输至该TEE中，以由该TEE基于自身的身份私钥对加密后的第二数据进行解密后，按照VC中指示的预先部署的计算任务对第二数据执行安全计算。然后，数据提供方22即可将该TEE生成的安全计算结果作为需返回至客户端21的用户数据。

由上述技术方案可知，本说明书的技术方案，将在用户的指示下颁发的可验证声明作为用户数据授权的凭证，使得用户可以通过该可验证声明控制数据提供方对应用的用户数据授权范围进行控制，避免了相关技术中用户无法控制用户数据授权范围的问题。

下面，以基于DID实现用户登录，并基于DID实现用户数据授权为例，对本说明书的技术方案进行介绍。

图3是本说明书一示例性实施例示出的一种用户登录方法的交互图。该方法可以包括以下步骤：

步骤301，客户端展示登录界面。

在本实施例中，用户在打开某一客户端后，即可在该客户端中展示相应的登录界面。例如，该客户端可以为Web页面或者某一应用程序的客户端，

步骤302，客户端在接收到用户的登录指示的情况下，基于用户的DID生成登录请求。

在本实施例中，通过用户的DID进行登录，因此，在登录界面中可以仅展示是否进行登录的控件，以便用户通过触发该控件指示客户端进行登录。当客户端接收到用户的登录指示之后，即可基于预先存储的用户的DID生成登录请求，并基于用户的身份私钥对生成的登录请求进行签名。

步骤303，客户端基于用户的身份私钥对登录请求进行签名。

步骤304，客户端将签名后的登录请求发送至认证方。

本实施例在生成登录请求，并基于用户的身份私钥对登录请求进行签名之后，即可将签名后的登录请求发送至认证方，以由认证方基于用户的身份公钥进行验签。

步骤305，认证方在接收到登录请求后，基于用户的DID生成公钥获取交易。

应当理解的是，用户的DID通过预先在区块链系统中注册得到，且区块链系统在为用户注册DID的过程中，生成了对应于该DID的DID文档，用于维护该用户的身份公钥。

因此，认证方在接收到登录请求后，即可基于用户的DID生成相应的公钥获取交易，以从区块链系统处获取用户的身份公钥。

步骤306，认证方将公钥获取交易发送至区块链系统。

步骤307，区块链系统基于获取到的公钥获取交易中包含的DID，获取用户的身份公钥并返回至认证方。

在本实施例中，区块链系统在接收到上述公钥获取交易之后，即可读取其中包含的用户的DID，以根据该DID查找到相应的DID文档，以将DID文档中包含的身份公钥返回至认证方。

步骤308，认证方基于返回的身份公钥对登录请求进行验签。

在本实施例中，认证方在接收到区块链系统返回的身份公钥之后，即可基于该身份公钥对接收到的VC进行验签。

步骤309，认证方在验签成功的情况下，向客户端返回登录授权信息。

在本实施例中，若验签成功，则证明请求登录的用户的身份可靠。此时，可以向客户端返回登录授权信息，以指示客户端将该用户的登录状态标记为已登录。

步骤310，客户端在接收到登录授权信息后，将用户的登录状态标记为已登录。

由上述技术方案可知，本实施例可以通过预先注册于区块链系统中的用户的DID，对请求登录的用户进行身份验证。应当理解的是，DID必须依托于区块链系统，因此，通过DID实现用户登录，相当于是基于区块链系统完成用户登录，由于区块链系统中的数据不可篡改，使得基于DID进行的身份认证具有较强的可靠性，避免了相关技术中由于通过中心化服务对用户进行身份认证，而导致的登录过程不可靠的问题。

图4是本说明书一示例性实施例示出的一种用户数据授权方法的交互图。该方法可以包括以下步骤：

步骤401，客户端在已登录用户的指示下运行第三方应用。

在本实施例中，以“在客户端中运行的第三方应用请求获取已登录用户的用户数据”为例进行介绍。

举例而言，本实施例中的客户端可以为即时通讯客户端，通常情况下，在该客户端上运行的应用为该客户端的原生服务方提供的原生应用，如，运行的为即时通讯应用。一般情况下，用户在完成登录后，客户端上运行的原生应用通常可以获取已登录用户的大多数用户数据，仅少部分数据需要在获得授权之后才能获取；而对于客户端上运行的由第三方服务方提供的第三方应用而言，若需要获取已登录用户的用户数据，必然需要优先获取该已登录用户的授权。

承接上述举例，在该即时通讯客户端中运行的第三方应用可以为由购物平台服务方提供的购物应用，此时，该购物应用需要获取已登录用户的数据，必然需要经由已登录用户的授权。

步骤402，客户端接收并展示第三方应用发起的用户数据获取请求。

承接上述举例，上述购物应用可以向客户端发起用户数据获取请求，例如，可以将该请求展示于客户端的界面之中，以便已登录用户确定是否授予该购物应用获取自身用户数据的权限。

步骤403，客户端接收到已登录用户的授权指示。

在本实施例中，需要声明的是，本说明书相较于相关技术中的用户数据授权方法，依托于不同的用户数据授权架构，其中，相关技术是依托于中心化服务器实现数据授权，而本说明书则是依托于分布式架构(包含区块链系统、数据提供方、认证方、客户端等)实现用户数据授权，本质上是在协议层面对用户数据授权过程进行了修改，或者说，是提出了一种新的用户数据授权协议，因此，在实际颁发VC时，是以令牌的形式进行颁发，即用户实际颁发的为VC令牌。

承接上述举例，若已登录用户为用户A，且已决定将自身的用户数据授权给购物应用B，则可以通过触发展示于客户端界面中的授权控件，以指示客户端生成用于指示“允许该购物应用B获取用户A的用户数据”的VC令牌。

步骤404，客户端基于用户的DID和第三方应用的DID颁发VC令牌。

在本实施例中，是基于DID实现用户数据的授权，因此，在颁发的VC令牌中实际上都是通过各个对象的DID表征相应的对象。

承接上述举例，假设用户A的DID为a1fdg4，购物应用B的DID为saff5d，那么，在VC令牌中即可通过a1fdg4表征用户A，通过saff5d表征购物应用B。当然除了两者的DID之外，还可以进一步限制用户A向购物应用B开放的用户数据的范围。例如，用户A的用户数据可以包括：用户名、昵称、即时通讯记录、用户头像、用户年龄等。而在VC令牌中则可以表明仅将用户名和用户头像的获取权限开放给该购物应用B。

步骤405，客户端基于第三方应用的身份私钥对VC令牌进行签名。

在本实施例中，为方便数据提供方在获取到VC令牌后，验证该VC令牌是否是颁发给第三方应用，在本步骤中，客户端可以基于第三方应用的身份私钥对VC令牌进行签名。

当然，在本步骤中，还可以进一步通过上述用户A的身份私钥对VC令牌进行签名，是否需要执行该步骤可由本领域技术人员根据实际需求确定，本实施例对此不作限制。

步骤406，客户端将完成签名的VC令牌发送至认证方。

在本实施例中，由于VC令牌存在时效性，因此，还可以将VC令牌注册至区块链系统中，以由区块链系统对用于表征VC令牌是否有效的状态信息进行维护。

由于在实际应用中，区块链技术提供方通常仅允许与其存在合作关系的服务方与区块链系统进行交互，因此，在本实施例中，可以优先将VC令牌发送至由该服务方提供的认证方处，以由该认证方生成相应的注册交易，以将VC令牌注册至区块链系统中。

步骤407，认证方基于签名后的VC令牌生成注册交易，并发送至区块链系统。

承接上述举例，区块链系统可以在接收到VC令牌的情况下直接对其进行注册，或者，在VC令牌经由用户A的身份私钥签名的情况下，可以优先根据VC令牌中用户A的DID获取链上存储的用户A的身份公钥，以对VC令牌进行验签，且仅在验签成功的情况下，再将VC令牌注册至区块链系统，并对其状态信息进行维护。需要声明的是，注册成功的VC令牌的状态信息被标记为有效，若在后续过程中，用户A不再将相应的用户数据授权给购物应用B，则可以通过向区块链系统发送吊销交易的方式将该VC令牌的状态信息变更为吊销状态。当然，用户A也可以预先在VC令牌中指示该VC令牌的有效时长，那么，区块链系统即可在完成注册之后，定时对该VC令牌进行吊销。

步骤408，区块链系统对VC令牌进行注册，并将注册得到的VC令牌的状态信息标记为有效。

步骤409，区块链系统将注册得到的VC令牌的DID返回至认证方。

在本实施例中，区块链系统在注册VC令牌时，可以生成对应于该VC令牌的DID，以便数据提供方可以根据该DID获取VC令牌的状态信息。

应当理解的是，本实施例仅仅是以通过VC令牌的DID获取VC令牌的状态信息为例进行介绍，在实际操作中，区块链系统只需返回对应于VC令牌的唯一标识信息，即可在后续验证过程中，获取该状态信息，例如，该唯一标识信息除了VC令牌的DID以外，还可以为VC令牌的hash值等，本实施例具体通过何种标识获取VC令牌的状态信息可由本领域技术人员根据实际情况确定，本实施例对此不作限制。

步骤410，认证方将VC令牌的DID返回至客户端。

步骤411，客户端基于签名后的VC令牌以及VC令牌的DID生成数据获取请求。

在本实施例中，当客户端接收到返回的VC令牌的DID之后，即可基于签名后的VC令牌以及该DID生成数据获取请求，并将其发送至数据提供方。

步骤412，客户端将数据获取请求发送至数据提供方。

在本实施例中，数据提供方可以为区别于上述认证方、区块链系统的其他数据服务器。该数据提供方通过区块链系统中注册的DID对VC令牌进行验证，而非听从认证方的认证结果。

步骤413，数据提供方基于第三方应用的DID，以及VC令牌的DID生成验证凭证获取交易。

承接上述举例，数据提供方在获取到数据获取请求之后，即可从该请求中读取签名后的VC令牌和VC令牌的DID，并进一步从VC令牌中获取购物应用B的DID。在此基础上，即可基于购物应用B的DID从区块链系统中获取购物应用B的身份公钥，以验证VC令牌中的被授权方是否为购物应用B；并基于VC令牌的DID从区块链系统处获取VC令牌的状态信息，以确定VC令牌是否有效。

步骤414，数据提供方将验证凭证获取交易发送至区块链系统。

在本实施例中，VC令牌的状态信息、第三方应用的身份公钥均用于对VC令牌进行验证，因此，可以将VC令牌的状态信息、第三方应用的身份公钥均称作验证凭证。

在实际操作中，数据提供方通常不会通过两次交互分别获取VC令牌的状态信息和第三方应用的身份公钥，而是通过一次交互获取VC令牌的状态信息和第三方应用的身份公钥。具体的，数据提供方可以基于VC令牌的DID和第三方应用的DID生成验证凭证获取交易，并将该验证凭证获取交易发送至区块链系统。

承接上述举例，基于VC令牌的DID和购物应用B的DID生成验证凭证交易，并发送至区块链系统。

步骤415，区块链系统执行验证凭证获取交易，以根据其中的第三方应用的DID获取第三方应用的身份公钥，根据其中的VC令牌的DID获取VC令牌的状态信息。

承接上述举例，区块链系统在接收到上述验证凭证获取交易之后，即可从中读取VC令牌的DID和购物应用B的DID，并根据购物应用B的DID获取购物应用B的身份公钥、根据其中的VC令牌的DID获取VC令牌的状态信息。

步骤416，区块链系统将第三方应用的身份公钥和VC令牌的状态信息返回至数据提供方。

步骤417，数据提供方基于第三方应用的身份公钥对VC令牌进行验签，并确定状态信息是否表明VC令牌有效；若验签成功且VC令牌有效，则跳转至步骤418。

承接上述举例，数据提供方在接收到区块链系统返回的VC令牌的状态信息和购物应用B的身份公钥之后，即可根据该状态信息确定该VC令牌是否有效，以及通过购物应用B的身份公钥对签名后的VC令牌进行验签。若确定VC令牌有效且验签成功，则证明购物应用B具有获取VC令牌中指示的用户数据的权限，数据提供方可以根据VC令牌中的指示获取相应的用户数据，并将其返回至客户端，以由客户端提供给购物应用B。

步骤418，数据提供方将VC令牌中指示的用户数据返回至客户端。

由上述技术方案可知，本实施例能够在用户的指示下为在客户端中运行的第三方应用颁发VC令牌，以通过该VC令牌指示数据提供方将相应的用户数据返回至客户端，并提供给第三方应用。应当理解的是，本实施例相当于将上述VC令牌作为数据授权凭证，以对用户数据授权过程进行控制，避免了相关技术中，用户无法对用户数据授权过程进行控制的问题。

进一步的，本实施例还可以进一步将VC令牌注册至区块链系统中，以由区块链系统对VC令牌的状态数据进行维护。在此基础上，数据提供方即可通过区块链系统获取VC令牌的状态信息，以确定VC令牌是否有效，进而避免了由于基于无效VC令牌将用户数据提供给第三方应用，而导致用户数据泄露的问题。

本说明书是参照根据本说明书实施例的方法、系统、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。

Claims (12)

1.一种用户数据授权方法，包括：

客户端在接收到用户的授权指示的情况下，基于所述用户的身份私钥、所述用户的分布式数字身份信息和所述客户端中的目标应用的分布式数字身份信息颁发可验证声明，所述可验证声明用于指示允许所述目标应用获取所述用户的用户数据；以及，所述客户端向数据提供方发送包含所述可验证声明的数据获取请求，且所述数据获取请求或所述数据获取请求中包含的可验证声明由所述目标应用的身份私钥进行签名；

数据提供方获取存储的关于所述用户的第二数据，并在所述可验证声明指示需要对所述第二数据进行安全计算的情况下，基于所述可验证声明中指示的可信执行环境身份公钥对所述第二数据进行加密传输，并将加密后的第二数据输入相应的可信执行环境中，以由所述可信执行环境在基于自身的身份私钥对加密后的第二数据进行解密后按照所述可验证声明指示的预先部署的计算任务执行安全计算；以及，将所述可信执行环境生成的安全计算结果作为所述可验证声明中指示的用户数据；

所述数据提供方从接收到的所述数据获取请求中读取可验证声明，并根据读取到的可验证声明中所含被授权方的分布式数字身份信息从区块链系统处获取相应的身份公钥，以通过获取到的身份公钥对接收到的数据获取请求或读取的可验证声明进行验签，并在验签成功的情况下，将读取的可验证声明中指示的用户数据返回所述客户端以提供至所述目标应用。

2.根据权利要求1所述的方法，

所述目标应用为所述客户端的原生服务方提供的原生应用；或者，

所述目标应用为区别于所述原生服务方的第三方服务方提供的第三方应用。

3.根据权利要求1所述的方法，所述客户端在接收到用户的授权指示的情况下，基于所述用户的身份私钥、所述用户的分布式数字身份信息和所述客户端中的目标应用的分布式数字身份信息颁发可验证声明，包括：

所述客户端在接收到所述用户的授权指示后，判断所述用户的登录状态；

在所述用户的登录状态为已登录的情况下，基于所述用户的身份私钥、所述用户的分布式数字身份信息和所述客户端中的目标应用的分布式数字身份信息颁发可验证声明。

4.根据权利要求3所述的方法，还包括：

所述客户端在接收到所述用户的登录请求的情况下，基于所述用户的身份私钥和分布式数字身份信息，向认证方发起登录请求；

所述认证方基于所述登录请求中包含的分布式数字身份信息从区块链系统处获取所述用户的身份公钥，以对所述登录请求进行验签，并在验签通过的情况下，向所述客户端返回登录授权信息；

所述客户端在接收到所述登录授权信息后，将所述用户的登录状态标记为已登录。

5.根据权利要求1所述的方法，还包括：

所述客户端将所述可验证声明注册至所述区块链系统，以由所述区块链系统对所述可验证声明的状态信息进行维护；

所述数据提供方在接收到所述可验证声明的情况下，从所述区块链系统中获取所述可验证声明的状态信息，并在所述状态信息表明所述可验证声明有效且针对所述可验证声明的验签成功的情况下，将所述用户数据返回至所述客户端。

6.根据权利要求5所述的方法，所述客户端将所述可验证声明注册至所述区块链系统，以由所述区块链系统对所述可验证声明的状态信息进行维护，包括：

所述客户端生成针对所述可验证声明的注册请求，并发送至认证方；

所述认证方在接收到所述注册请求的情况下，生成包含所述可验证声明的注册交易并发送至所述区块链系统；

所述区块链系统执行所述注册交易，以对接收到的可验证声明进行存证并维护所述可验证声明的状态信息。

7.根据权利要求5所述的方法，还包括：

所述客户端在接收到所述用户针对所述可验证声明的吊销请求的情况下，指示所述区块链系统将所述可验证信息的状态信息变更为吊销状态。

8.根据权利要求1所述的方法，所述数据获取请求或所述数据获取请求中包含的可验证声明还经由所述用户的身份私钥进行签名；所述方法还包括：

所述数据提供方在读取所述可验证声明之后，根据读取到的可验证声明中所含授权方的分布式数字身份信息从所述区块链系统处获取相应的身份公钥，以对所述可验证声明进行验签；

其中，所述数据提供方仅在基于所述授权方的身份公钥执行的验签操作、以及基于所述被授权方的身份公钥执行的验签操作均通过的情况下，将所述用户数据返回至所述客户端。

9.根据权利要求1所述的方法，

所述数据提供方为区别于所述区块链系统的数据服务器；或者，

所述数据提供方为所述区块链系统。

10.根据权利要求1所述的方法，还包括：

所述客户端将所述可验证声明发送至中转服务器；

所述中转服务器根据所述用户的分布式数字身份信息从数据网络包含的若干数据服务器中确定出存储有所述用户数据的数据服务器，以将确定出的数据服务器作为所述数据提供方。

11.根据权利要求1所述的方法，所述基于所述可验证声明中指示的可信执行环境身份公钥对所述第二数据进行加密传输，并将加密后的第二数据输入相应的可信执行环境中，以由所述可信执行环境在基于自身的身份私钥对加密后的第二数据进行解密后按照所述可验证声明指示的预先部署的计算任务执行安全计算，包括：

所述数据提供方基于所述可验证声明中指示的链上可信执行环境的身份公钥，对所述第二数据进行加密，并基于加密后的第二数据以及所述可验证声明中所含的计算任务生成安全计算交易；

隐私区块链在接收到所述安全计算交易的情况下，在自身维护的链上可信执行环境中执行所述安全计算交易，以在通过所述链上可信执行环境的身份私钥对所述第二数据进行解密后，调用预先部署的用于完成所述计算任务的智能合约，对解密后的第二数据进行安全计算。

12.一种用户数据授权系统，包括：客户端和数据提供方；其中，

所述客户端在接收到用户的授权指示的情况下，基于所述用户的身份私钥、所述用户的分布式数字身份信息和所述客户端中的目标应用的分布式数字身份信息颁发可验证声明，所述可验证声明用于指示允许所述目标应用获取所述用户的用户数据；以及，所述客户端向所述数据提供方发送包含所述可验证声明的数据获取请求，且所述数据获取请求或所述数据获取请求中包含的可验证声明由所述目标应用的身份私钥进行签名；

所述数据提供方获取存储的关于所述用户的第二数据，并在所述可验证声明指示需要对所述第二数据进行安全计算的情况下，基于所述可验证声明中指示的可信执行环境身份公钥对所述第二数据进行加密传输，并将加密后的第二数据输入相应的可信执行环境中，以由所述可信执行环境在基于自身的身份私钥对加密后的第二数据进行解密后按照所述可验证声明指示的预先部署的计算任务执行安全计算；以及，将所述可信执行环境生成的安全计算结果作为所述可验证声明中指示的用户数据；以及，从接收到的所述数据获取请求中读取可验证声明，并根据读取到的可验证声明中所含被授权方的分布式数字身份信息从区块链系统处获取相应的身份公钥，以通过获取到的身份公钥对接收到的数据获取请求或读取的可验证声明进行验签，并在验签成功的情况下，将读取的可验证声明中指示的用户数据返回所述客户端以提供至所述目标应用。

Images