WO2022252992A1

WO2022252992A1 - User data authorization method and user data authorization system

Info

Publication number: WO2022252992A1
Application number: PCT/CN2022/093793
Authority: WO
Inventors: 孙善禄; 李书博
Original assignee: 支付宝(杭州)信息技术有限公司; 蚂蚁区块链科技(上海)有限公司
Priority date: 2021-06-01
Filing date: 2022-05-19
Publication date: 2022-12-08
Also published as: CN113312664A; CN113312664B

Abstract

A user data authorization method and a user data authorization system. The method may comprise: a client issuing a verifiable claim on the basis of an identity private key and distributed digital identity information of a user, and distributed digital identity information of a target application in the client, wherein the verifiable claim is used for indicating that the target application is allowed to acquire user data of the user, and the client signing the verifiable claim by means of an identity private key of the target application, and adding the signed verifiable claim to a data acquisition request, so as to send the data acquisition request to a data provider (102); and after receiving the data acquisition request, the data provider acquiring an identity public key of an authorized party on the basis of distributed digital identity information of the authorized party that is included in the verifiable claim, so as to perform signature verification on the verifiable claim by means of the identity public key, and returning, to the client, the user data that is indicated in the verifiable claim when the signature verification is passed, so as to provide the user data to the target application (104).

Description

User data authorization method and user data authorization system

technical field

One or more embodiments of this specification relate to the technical field of terminals, and in particular, to a user data authorization method and a user data authorization system.

Background technique

In related technologies, if the application in the client needs to obtain user data, it only needs to be authenticated by the authenticator corresponding to the client, and the data provider will follow the authentication result of the authenticator and return its information to the corresponding application. The requested user data. It is not difficult to see that in the process of obtaining user data in related technologies, the user cannot control the scope of the user data returned by the data provider.

Contents of the invention

In view of this, one or more embodiments of this specification provide a user data authorization method and a user data authorization system.

One or more embodiments of this specification provide the following technical solutions: According to the first aspect of one or more embodiments of this specification, a user data authorization method is proposed, including: when the client receives an authorization instruction from the user , issuing a verifiable statement based on the identity private key of the user, the distributed digital identity information of the user, and the distributed digital identity information of the target application in the client, and the verifiable statement is used to indicate that the The target application acquires the user data of the user; and, the client sends a data acquisition request including the verifiable statement to the data provider, and the data acquisition request or the verifiable statement included in the data acquisition request Signed by the identity private key of the target application; the data provider reads the verifiable statement from the received data acquisition request, and according to the distributed number of the authorized party contained in the read verifiable statement The identity information obtains the corresponding identity public key from the blockchain system to verify the signature of the received data acquisition request or the read verifiable statement through the obtained identity public key, and if the signature verification is successful, User data indicated in the read verifiable statement is returned to the client for provision to the target application.

According to a second aspect of one or more embodiments of the present specification, a user data authorization system is proposed, including: a client and a data provider; wherein, when the client receives an authorization instruction from the user, based on The user's identity private key, the user's distributed digital identity information, and the distributed digital identity information of the target application in the client issue a verifiable statement, and the verifiable statement is used to indicate that the target application is allowed to Obtain the user data of the user; and, the client sends a data acquisition request containing the verifiable statement to the data provider, and the data acquisition request or the verifiable statement contained in the data acquisition request Signed by the identity private key of the target application; the data provider reads the verifiable statement from the received data acquisition request, and according to the distribution of authorized parties contained in the read verifiable statement The digital identity information obtains the corresponding identity public key from the blockchain system, so as to verify the signature of the received data acquisition request or the read verifiable statement through the obtained identity public key, and when the signature verification is successful Next, the user data indicated in the read verifiable statement is returned to the client for provision to the target application.

Description of drawings

Fig. 1 is a flowchart of a user data authorization method provided by an exemplary embodiment.

Fig. 2 is a schematic diagram of a user data authorization system provided by an exemplary embodiment.

Fig. 3 is an interaction diagram of a user login method provided by an exemplary embodiment.

Fig. 4 is an interaction diagram of a user data authorization method provided by an exemplary embodiment.

Detailed ways

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. Implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with aspects of one or more embodiments of the present specification as recited in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or less steps than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.

In the related technology, if the application in the client needs to obtain the user data of the user, only the authenticator corresponding to the client needs to complete the authentication of the user, and can instruct the corresponding data provider to provide the user data of the user to the above-mentioned application.

It should be understood that the data provider in the related technology is equivalent to returning user data to the application according to the authentication result of the authenticator, which makes it impossible for the user to control the data provider's operation of providing user data for the application, which in turn leads to the data provider's direction to the application. When providing user data, there is only a distinction between provision and non-provision, but the scope of the provided user data cannot be controlled. In addition, since the data provider directly obeys the authentication result of the authorizer for authorization, there is no authorization certificate, so the data provider cannot self-certify the above authorization process in the subsequent traceability process.

In order to solve the above problems, this specification proposes a user data authorization method, which enables users to control the authorization scope of user data open to applications from data providers, and avoids the problem of being unable to control the authorization scope of user data in related technologies.

Fig. 1 is a flow chart of a user data authorization method shown in an exemplary embodiment of this specification. The method may include the following steps: Step 102, when the client receives the user's authorization instruction, based on the user's identity private key, the user's distributed digital identity information and the target application in the client The distributed digital identity information issues a verifiable statement, and the verifiable statement is used to indicate that the target application is allowed to obtain the user data of the user; and, the client sends to the data provider a message containing the verifiable statement A data acquisition request, and the data acquisition request or the verifiable statement contained in the data acquisition request is signed by the identity private key of the target application.

In view of the technical problems in related technologies caused by the fact that the data provider obeys the authentication result of the authenticator and provides user data to the application, this disclosure no longer relies on the authentication result of the above-mentioned authenticator to authorize user data, but through the user The method of issuing VC (Verifiable Claim) to the application requesting to obtain user data, instructing the data provider to authorize the user data of the application. Wherein, the VC may contain information such as the authorizer, the authorized party, and authorized content. Specifically, in the VC issued in this manual, the authorizing party is the user corresponding to the client, and the authorized party is the application requesting to obtain user data, and the authorized content may include the scope of the authorized user data.

It should be understood that since this specification instructs the data provider to authorize user data by issuing VC, users in this specification can control the scope of authorization of their own data and other content, avoiding the need for users to authorize data in related technologies. Uncontrollable, resulting in too large user data authorization scope, which in turn leads to excessive information leakage. Secondly, since the data provider authorizes user data based on VC, in the subsequent traceability process, VC can prove to the traceable party that it is based on the user's instruction to open the permission to the corresponding application to obtain user data. In other words, through the technical solution of this specification, the data provider can self-certify the data authorization operation in the subsequent traceability process.

What needs to be declared is that VC needs to be issued based on DID (Decentralized Identifiers, distributed digital identity), and DID is registered in the blockchain system. It can be seen that this manual is equivalent to relying on the distributed architecture of the blockchain system to carry out user data Authorization avoids the problems caused by relying on centralized services in related technologies. In actual operation, the DIDs of the above-mentioned users, clients, applications, etc. can be pre-registered in the blockchain system for issuing VC and verifying VC. Specifically, when registering a DID for any object, a corresponding registration transaction can be generated based on the description information and identity public key of any object, and the generated registration transaction can be sent to the blockchain system; the blockchain system can Execute the received registration transaction to generate the DID and DID document corresponding to any object, and maintain the identity public key and description information contained in the registration transaction in the DID document. On this basis, when any device needs to authenticate any object, it only needs to provide the DID of any object, and then it can obtain the identity public key of any object from the blockchain system, based on The identity public key verifies the signature information signed by the identity private key of any object, and then completes the identity authentication for any object.

In this specification, after receiving the user data authorization request initiated by the target application, the client can communicate the user data authorization request to the user, so that the user can determine whether to grant the target application access to the corresponding data. Among them, after receiving the user's authorization instruction, the client can further determine whether the user is already logged in. If the user is already logged in, the user's identity private key, the user's distributed digital identity information and the The distributed digital identity information of the target application issues the above verifiable statement; otherwise, the verifiable statement is not issued.

On this premise, in order to enable the client to normally execute the operation of issuing a verifiable statement under the condition of obtaining the authorization of the user, this manual may also include the steps for the user to log in on the client: In one embodiment, the user can Log in through the method in related technologies, that is, based on centralized services. Specifically, the client can display a login interface to the user so that the user can enter corresponding user authentication information, such as account number and password; on this basis, the client can generate a corresponding authentication request based on the user authentication information and send it to the At the authenticator corresponding to the client, after verifying the user authentication information, the authenticator can return login authorization information to the client to instruct the client to mark the user's login status as logged in.

In another embodiment, users can log in through their own DID pre-registered in the blockchain system. Specifically, when receiving a login request from a user, the client can initiate a login request to the authenticator corresponding to the client based on the user's identity private key and DID; and the authenticator, after receiving the login request, immediately Based on the DID contained in it, the user's identity public key can be obtained from the blockchain system to verify the login request, and if the verification is passed, the login authorization information is returned to the client; the client receives the login After authorizing information, the user's login status can be marked as logged in.

It should be understood that if the user authentication information such as account number and password is used to log in, it essentially compares the authentication information entered by the user with the pre-registered authentication information in the centralized server to determine whether the user has successfully logged in. However, the data stored in the centralized server is controlled by the service provider and is easily tampered with, making the entire login process unreliable. In this embodiment, the user's pre-registered DID in the blockchain system is used as the login credential, and since the DID is registered in the blockchain system (equivalent to the login credential having the endorsement of the blockchain system), it has an inherent The nature of tampering makes this embodiment more reliable than logging in through centralized services.

In this specification, the application that requests to obtain user data is named the target application. In practical applications, the target application may be a native application provided by the native server of the client, or a third-party application provided by a third-party server different from the native server. Wherein, when the target application is a third-party application, the third-party application may be a small program, an H5 page, etc. running in the client.

For example, when the client is an instant messaging client, if the above-mentioned target application is the above-mentioned native application, the target application can be an instant messaging application running on the instant messaging client; if the above-mentioned target application is the above-mentioned third-party application, the The target application may be a shopping application provided by a shopping platform service provider running on the instant messaging client (for example, it may be presented in the form of a small program or an H5 page). Of course, this example is only illustrative, and the specific application of the above-mentioned target application and third-party application can be determined by those skilled in the art according to the actual situation.

In this specification, the target application can initiate a data authorization request to the user through the client, for example, by displaying the data authorization request on the interface, or by broadcasting the data authorization request, the user can be notified that the target application requests to obtain user data ; and the user can respond to the data authorization request to send an authorization instruction for the target application to the client. On this basis, the client can issue a VC based on the user's identity private key, the user's DID, and the target application's DID. The VC is used to indicate that the target application is allowed to obtain the user's user data; after completing the VC issuance, the client That is, a data acquisition request including the VC can be further sent to the data provider, and the data acquisition request or the VC contained in the data acquisition request is signed by the identity private key of the target application.

Step 104, the data provider reads the verifiable statement from the received data acquisition request, and obtains it from the blockchain system according to the distributed digital identity information of the authorized party contained in the read verifiable statement The corresponding identity public key is used to verify the signature of the received data acquisition request or the read verifiable statement through the obtained identity public key, and if the signature verification is successful, it will indicate in the read verifiable statement The user data is returned to the client for provision to the target application.

In this specification, when the data provider receives the above data acquisition request, it can read the VC from it, and obtain the authorized party's identity public key from the blockchain system according to the authorized party's DID contained in the VC, The data acquisition request or VC can be verified through the identity public key. If the signature verification is successful, it proves that the target application is the issued party in the VC, and the user data indicated in the VC can be returned to the client to be provided to the target application.

It needs to be declared that although related technologies need to verify both the authorizer and the authorized party included in the VC when verifying the VC, in this specification, only the authorized party needs to be verified. The reason is: VC must be issued based on the DID registered in the blockchain system, which is inherently reliable, so there is no need to verify whether the VC is credible; and this manual focuses on "whether the target application has obtained user data authorization", but It doesn't care about "who grants this permission". In other words, the authorizing party included in the VC of this specification can be the above-mentioned user itself, or other objects that can authorize the user data of the user. Therefore, in this manual, when issuing a VC, the user only needs to verify the signature through the identity private key of the target application; Signature verification is performed to determine whether the target application has permission to obtain the corresponding user data.

It should be understood that although this specification can only verify the authorized party in the VC, in practical applications, as in related technologies, the authorizing party in the VC can also be verified, and only between the authorizing party and the authorized party If both parties pass the verification, then return the user data indicated in the VC to the client. Specifically, while the VC issued by the user is signed by the identity private key of the target application, it can be further signed by the user's identity private key; on this basis, after receiving the VC, the data provider can, according to the The DID of the authorizer obtains the identity public key of the authorizer from the blockchain system to verify the signature of the VC based on the identity public key. If the verification is successful, it proves that the authorizer in the VC is the user. In this embodiment, the data provider only transfers the corresponding user data to Return to client.

The above method of verifying both the authorizer and the authorized party in VC is equivalent to strict standards for the target application to obtain user data authorization, that is, only when it is determined that the user itself grants the target application the permission to obtain its user data , the data provider provides the user data indicated in the VC to the target application.

In practical applications, the issued VC has a certain timeliness, and whether the VC is valid can be determined according to the preset valid time, or can be changed according to the user's instruction. This can be determined by those skilled in the art according to actual needs, and the present disclosure does not limit it.

In this specification, the state information of VC can be maintained by registering VC to the blockchain system, so that the data provider can determine the validity of VC through the state information maintained in the blockchain system after receiving the VC. sex. Among them, the data provider returns the user data indicated in the VC to the client only when it is determined that the state information maintained in the blockchain system indicates that the VC is valid and the verification of the verifiable statement is successful.

In practical applications, the data provider can obtain VC status information in a variety of ways. For example, after the user completes the issuance of VC, the client can generate a corresponding registration transaction and send it to the blockchain system for The system generates the DID corresponding to the VC, and stores the VC's DID and status information in association. On this basis, after receiving the VC, the data provider can provide the VC's DID to the blockchain system to According to the DID, the blockchain system obtains the status information of the VC and returns it to the data provider. Of course, this example is only illustrative, and how to obtain the status information of the VC can be determined by those skilled in the art according to actual needs, and this specification does not limit it.

It needs to be declared that although the above operation of registering VC in the blockchain system can be completed by direct interaction between the client and the blockchain system. However, in most of today's blockchain architectures, usually only the service party that has a cooperative relationship with the blockchain technology provider is allowed to interact with the blockchain system, and the service party can be responsible for the above-mentioned user authentication information The authenticating party performing the authentication. Therefore, when the client in this specification needs to register a VC with the blockchain system, it can generate a registration request for the VC and send the generated registration request to the authenticator; after the authenticator receives the registration request, it can Based on the VC contained in the registration request, a registration transaction is generated and sent to the blockchain system; the blockchain system can execute the registration transaction to store the VC contained in the transaction and maintain the status information of the VC .

As mentioned above, whether or not VC is valid can be changed according to the user's instruction. Correspondingly, after registering VC to the blockchain system, if the user needs to invalidate the registered VC, he can send a revocation request for the registered VC to the client. After receiving the revocation request, the client can Instruct the blockchain system to change the status information of the registered VC to the revoked status, which is used to indicate that the VC has been invalidated by the above-mentioned user.

In this specification, the above-mentioned data provider can be either a blockchain system or a data server different from the blockchain system.

Wherein, when the above-mentioned data provider is a data server different from the blockchain system, the data server may belong to a certain data network. In this case, the client can preferentially send the VC to the transit server corresponding to the data network, so that the transit server can determine the user data indicated in the VC from several data servers included in the data network according to the user's DID. data server, and send the VC to the determined data server.

When the above-mentioned data provider is a blockchain system, the client can generate a corresponding data acquisition transaction based on VC and send it to the blockchain system, so that the blockchain system can use the user's DID or user data contained in the VC to The description information of , obtain the user data that needs to be returned to the client from the maintained chain data.

Of course, the above examples are all illustrative, how to obtain the user data indicated in the VC from the data provider can be determined by those skilled in the art according to the actual situation, and this specification does not limit it.

In this specification, the VC should contain the description information of the user data to be obtained, so that after receiving the VC, the data provider can obtain the stored first data about the user according to the description information in it, and return to the Client user data.

However, in practical applications, the user's user data contains a large amount of private data, which is usually inconvenient to be directly disclosed to the target application. Therefore, if the target application requires the obtained data to contain private data, the user can also Further, the form in which the data provider provides the user data to the target application is restricted. For example, it may be stipulated that: after obtaining the stored second data about the user according to the description information in the VC, process the second data according to the instruction in the VC, and use the processing result as the user data that needs to be returned to the client. For example, when the target application needs to confirm whether the user is an adult, the user data it requests may be the age of the user. At this time, the data provider in this disclosure can determine whether the age of the user is More than 18, and return the conclusion of "whether it is an adult" to the client according to the judgment result as the above user data. It should be understood that, in this manner, leakage of the user's private data can be avoided, and the security of the user data is improved.

In order to further ensure the security of user data, after the data provider obtains the above-mentioned second data, it may further perform processing operations on the second data in a TEE (Trusted execution environment, trusted execution environment). Specifically, the VC issued by the user may also include: an indication that secure calculation needs to be performed on the acquired second data, and indication information of a TEE used for performing secure calculation. Then, after obtaining the second data, the data provider can encrypt the obtained second data based on the identity public key of the TEE indicated in the VC, and transmit it to the TEE, so that the TEE can obtain the second data based on its own identity. After the private key decrypts the encrypted second data, security calculations are performed on the second data according to the pre-deployed calculation tasks indicated in the VC. Then, the data provider can use the security calculation result generated by the TEE as the user data that needs to be returned to the client.

In practical applications, the above TEE can be deployed in both privacy blockchains and off-chain privacy computing nodes.

Among them, when deployed in a privacy blockchain, the above TEE is an on-chain TEE. After obtaining the VC, the data provider can encrypt the obtained second data based on the identity public key of the on-chain TEE indicated in the VC, and based on the encrypted second data and the computing tasks contained in the VC A secure computing transaction is generated, and the secure computing transaction is sent to the privacy blockchain; after the privacy blockchain receives the secure computing transaction, it can execute the secure computing transaction in the TEE on the chain maintained by itself, so as to pass the chain After the identity private key on the TEE decrypts the second data, it calls the pre-deployed smart contract for completing the above calculation tasks, and performs secure calculation on the decrypted second data.

What needs to be declared is that the privacy blockchain can be either the above-mentioned blockchain system or other blockchain systems different from the above-mentioned blockchain system. How to deploy the privacy blockchain can be determined by those skilled in the art. It is determined according to the actual situation, and this specification does not limit it.

Of course, no matter whether the above TEE is deployed on-chain or off-chain, after completing the security calculation, the security calculation result can be encrypted with the identity public key of the target application first, and then the security calculation result can be output and transmitted to the client , to further ensure the security of user data.

Secondly, it also needs to be emphasized that the blockchain system in this specification can be carried on the traditional architecture of blockchain technology, that is, all nodes in the blockchain system can deploy the blockchain code on the corresponding physical equipment Formed, in most cases, each node corresponds to a physical device; the technical solution in this manual can also be carried on the BaaS (Blockchain as a Service) architecture in blockchain technology, that is, all Nodes are formed by deploying blockchain codes on virtual machines implemented in the cloud through cloud services, and blockchain nodes do not need to correspond to corresponding physical devices one by one. In this architecture, it is also included for each blockchain node to provide The blockchain-as-a-service BaaS platform (or BaaS cloud) can provide pre-written software through activities that occur on the blockchain (such as subscriptions and notifications, user verification, database management, and remote updates). The client-side computing equipment connected to the BaaS platform provides easy-to-use, one-click deployment, fast verification, flexible and customizable blockchain services, which can accelerate the development, testing, and launch of blockchain business applications and help various industry regions The landing of blockchain business application scenarios. Corresponding to this manual, the fast signature verification of VC can be realized through the BaaS platform to improve the efficiency of data acquisition.

It can be seen from the above technical solution that when this manual needs to provide user data to the application in the client, it will firstly use the user's identity private key, distributed digital identity information, and the distributed digital identity of the application under the user's consent. information, issuing verifiable claims. Wherein, the verifiable statement is used to indicate that the above-mentioned application is allowed to obtain the user data of the above-mentioned user. On this basis, the client can further send a data acquisition request containing the verifiable statement to the data provider, and the data acquisition request or the verifiable statement is signed by the identity private key of the target application. Correspondingly, after receiving the data acquisition request, the data provider can obtain the identity public key of the authorized party according to the distributed digital identity information of the authorized party contained in the verifiable statement, so as to respond to the verifiable statement or data acquisition request. Check the signature.

It should be understood that the data provider in this specification verifies the verifiable statement or data acquisition request based on the identity public key of the authorized party, which is equivalent to verifying whether the authorized party in the verifiable statement is requesting to obtain user data target application. Obviously, if the signature verification is successful, it can be proved that the target application has obtained the permission to obtain the user data indicated in the verifiable statement. It can be seen that this manual uses the verifiable statement as the certificate for the user to authorize the user data of the target application. The user can clearly indicate in the verifiable statement which user data to provide to the above-mentioned application, so that the user can control the scope of user data authorization. control, which avoids the problem that users cannot control the authorization scope of user data due to the use of centralized services for user data authorization in related technologies; in addition, since the verifiable statement is sent to the data provider, the data In the follow-up traceability process, the provider can self-certify to the traceable party that the user data authorization process is completed under the user's instructions, avoiding the lack of authorization credentials in related technologies, which makes the data provider unable to self-certify the user data authorization operation The problem.

Further, related technologies log in through centralized services, and the authenticator and data provider are provided by the same service provider, and the data provider follows the authentication results of the authenticator to authorize user data, that is, the authenticator and data provider in related technologies They are bound to each other and cannot be decoupled. In this specification, the data provider returns user data to the client based on the issued verifiable statement, without relying on the authentication result of the authenticator. It can be seen that the technical solution in this specification realizes the decoupling of the authenticator and the data provider. The two can be provided by different service parties, which improves the applicability of the user data authorization method.

Furthermore, after the data provider in this manual obtains the data indicated by the verifiable statement, it can further process the obtained data, and only return the processing result to the client without returning the original data The problem of leakage of user privacy data in related technologies is avoided.

This specification also proposes a user data authorization system for implementing the above user data authorization method. It should be declared that most of the operation methods in the next embodiment, such as how to issue a verifiable statement, how to verify the verifiable statement, how to perform secure calculation, etc., are similar to the previous embodiment, and the specific operation methods are all Reference may be made to the introduction of the previous embodiment, which will not be described in detail below.

Fig. 2 is a schematic diagram of a user data authorization system shown in an exemplary embodiment of this specification. The system may include: a client 21 and a data provider 22; wherein, when the client 21 receives the user's authorization instruction, based on the user's identity private key, the user's distributed digital identity information and the client's The distributed digital identity information of the target application in the terminal 21 issues a verifiable statement, and the verifiable statement is used to indicate that the target application is allowed to obtain the user data of the user; and, the client 21 sends to the data provider A data acquisition request containing the verifiable statement, and the data acquisition request or the verifiable statement contained in the data acquisition request is signed by the identity private key of the target application; the data provider 22 receives from Read the verifiable statement in the data acquisition request, and obtain the corresponding identity public key from the blockchain system according to the distributed digital identity information of the authorized party contained in the read verifiable statement, so as to obtain The received identity public key verifies the received data acquisition request or the read verifiable statement, and if the verification is successful, returns the user data indicated in the read verifiable statement to the client 21 to provide to the target application.

As mentioned above, in this specification, the user needs to be in the logged-in state in the client 21 before receiving the application's user data authorization request. Therefore, the operation of the user logging in on the client 21 may also be included in this description. In an embodiment, the user can log in through a method in related technologies, that is, based on a centralized service. In another embodiment, users can log in through their own DID pre-registered in the blockchain system. Specifically, the client 21 may initiate a login request to the authenticator corresponding to the client 21 based on the user's identity private key and DID when receiving the user's login request; and the authenticator, after receiving the login request, , the user’s identity public key can be obtained from the blockchain system based on the DID contained therein to verify the login request, and return the login authorization information to the client 21 if the signature verification is passed; on this basis Above, after receiving the login authorization information, the client 21 can mark the user's login status as logged in.

As described above, this specification names the application that requests user data as the target application. Wherein, the target application may be a native application provided by the native server of the client 21, or a third-party application provided by a third-party server different from the native server.

As mentioned above, this specification can only verify the authorized party in the VC, or can verify both the authorizing party and the authorized party in the VC as in the related art.

As mentioned above, the issued VC has a certain timeliness, and whether the VC is valid can be determined according to the preset valid time, or can be changed according to the user's instruction. This can be determined by those skilled in the art according to actual needs, and the present disclosure does not limit it. Specifically, this specification can maintain the status information of VC by registering the VC in the blockchain system, so that the data provider 22 can determine the status information of the VC through the status information maintained in the blockchain system when receiving the VC. effectiveness. Among them, the data provider 22 returns the user data indicated in the VC to the client 21 only when it is determined that the status information maintained in the blockchain system indicates that the VC is valid and the verification of the verifiable statement is successful.

As mentioned above, when the client 21 in this specification needs to register the VC to the blockchain system, it can generate a registration request for the VC, and send the generated registration request to the authenticator; after the authenticator receives the registration request , based on the VC contained in the registration request, a registration transaction can be generated and sent to the blockchain system; the blockchain system can execute the registration transaction to deposit the VC contained in the transaction and maintain the VC status information.

As mentioned above, the client 21 in this specification can also instruct the blockchain system to change the status information of the registered VC to the revoked state when receiving the revocation request sent by the user for the registered VC.

As mentioned above, the data provider 22 in this specification can be either a blockchain system or a data server different from the blockchain system.

As mentioned above, in the case that the data provider 22 belongs to a certain data network, the client 21 can preferentially send the VC to the transit server corresponding to the data network, so that the transit server can obtain the VC contained in the data network according to the DID of the user. The data provider 22 storing the user data indicated in the VC is determined among the several data providers 22, and the VC is sent to the determined data provider 22.

As mentioned above, in this specification, the data provider 22 can obtain the stored first data about the user according to the instructions of the VC as the user data to be returned to the client 21; Instruct to acquire the stored second data about the user, and process the second data according to the instructions of the VC, so as to use the processing result as the user data to be returned to the client 21 .

As mentioned above, in order to further ensure the security of user data, after the data provider 22 acquires the above-mentioned second data, it may further perform processing operations on the second data in the TEE. Specifically, the VC issued by the user may also include: an indication that secure calculation needs to be performed on the acquired second data, and indication information of a TEE used for performing secure calculation. Then, after obtaining the second data, the data provider 22 can encrypt the obtained second data based on the identity public key of the TEE indicated in the VC, and transmit it to the TEE, so that the TEE can encrypt the obtained second data based on its own identity public key. After the identity private key decrypts the encrypted second data, security calculations are performed on the second data according to the pre-deployed calculation tasks indicated in the VC. Then, the data provider 22 can use the security calculation result generated by the TEE as the user data to be returned to the client 21 .

It can be seen from the above technical solution that the technical solution in this manual uses the verifiable statement issued under the instruction of the user as the credential for user data authorization, so that the user can use the verifiable statement to control the data provider's authorization of the application's user data. control, which avoids the problem in related technologies that the user cannot control the authorized scope of user data.

In the following, the technical solution of this manual will be introduced by taking DID-based implementation of user login and DID-based implementation of user data authorization as examples.

Fig. 3 is an interaction diagram of a user login method shown in an exemplary embodiment of this specification. The method may include the following steps: Step 301, the client displays a login interface.

In this embodiment, after the user opens a certain client, the corresponding login interface can be displayed in the client. For example, the client may be a client of a web page or an application program. In step 302, the client generates a login request based on the user's DID after receiving the user's login instruction.

In this embodiment, the user's DID is used to log in. Therefore, only a control of whether to log in may be displayed on the login interface, so that the user can instruct the client to log in by triggering the control. After the client receives the user's login instruction, it can generate a login request based on the pre-stored user's DID, and sign the generated login request based on the user's identity private key.

Step 303, the client signs the login request based on the user's identity private key.

Step 304, the client sends the signed login request to the authenticator.

In this embodiment, after the login request is generated and signed based on the user's identity private key, the signed login request can be sent to the authenticator, so that the authenticator can verify the signature based on the user's identity public key.

Step 305, after receiving the login request, the authenticator generates a public key acquisition transaction based on the user's DID.

It should be understood that the user's DID is obtained by pre-registering in the blockchain system, and the blockchain system generates a DID document corresponding to the DID during the process of registering the DID for the user to maintain the user's identity public key.

Therefore, after receiving the login request, the authenticator can generate a corresponding public key acquisition transaction based on the user's DID to obtain the user's identity public key from the blockchain system.

Step 306, the authenticator sends the public key acquisition transaction to the blockchain system.

Step 307, the blockchain system obtains the DID included in the transaction based on the obtained public key, obtains the user's identity public key and returns it to the authenticator.

In this embodiment, after the blockchain system receives the above-mentioned public key acquisition transaction, it can read the user's DID contained in it, so as to find the corresponding DID document according to the DID, so that the identity contained in the DID document The public key is returned to the authenticator.

In step 308, the authenticator verifies the login request based on the returned identity public key.

In this embodiment, after receiving the identity public key returned by the blockchain system, the authenticator can verify the received VC based on the identity public key.

In step 309, the authenticator returns login authorization information to the client if the signature verification is successful.

In this embodiment, if the signature verification is successful, it proves that the identity of the user requesting to log in is reliable. At this point, login authorization information may be returned to the client to instruct the client to mark the user's login status as logged in.

Step 310, after receiving the login authorization information, the client marks the user's login status as logged in.

It can be seen from the above technical solution that in this embodiment, the user who requests to log in can be authenticated by using the DID of the user pre-registered in the blockchain system. It should be understood that DID must rely on the blockchain system. Therefore, user login through DID is equivalent to completing user login based on the blockchain system. Since the data in the blockchain system cannot be tampered with, the identity based on DID The authentication has strong reliability, which avoids the problem of unreliable login process caused by the authentication of the user through the centralized service in the related technology.

Fig. 4 is an interaction diagram of a user data authorization method shown in an exemplary embodiment of this specification. The method may include the following steps: Step 401, the client runs a third-party application under the instruction of the logged-in user.

In this embodiment, "the third-party application running on the client requests to obtain the user data of the logged-in user" is taken as an example for introduction.

For example, the client in this embodiment may be an instant messaging client. Usually, the application running on the client is a native application provided by the client's native server, such as an instant messaging application. . In general, after the user completes the login, the native application running on the client can usually obtain most of the user data of the logged-in user, and only a small part of the data can only be obtained after obtaining authorization; For the third-party application provided by the third-party service provider, if it needs to obtain the user data of the logged-in user, it must first obtain the authorization of the logged-in user.

Following the above example, the third-party application running in the instant messaging client can be a shopping application provided by the shopping platform service provider. At this time, the shopping application needs to obtain the data of the logged-in user, which must be authorized by the logged-in user. .

Step 402, the client receives and displays the user data acquisition request initiated by the third-party application.

Following the above example, the above shopping application can initiate a user data acquisition request to the client, for example, the request can be displayed on the client interface, so that the logged-in user can determine whether to grant the shopping application permission to obtain its own user data.

Step 403, the client receives an authorization instruction from the logged-in user.

In this embodiment, it needs to be declared that, compared with the user data authorization method in the related technology, this specification relies on a different user data authorization framework, wherein the related technology relies on a centralized server to implement data authorization, while this The manual relies on the distributed architecture (including blockchain system, data provider, authenticator, client, etc.) to realize user data authorization, which essentially modifies the user data authorization process at the protocol level, or in other words, is A new user data authorization protocol is proposed. Therefore, when VC is actually issued, it is issued in the form of a token, that is, what the user actually issues is a VC token.

Continuing the above example, if the logged-in user is user A and has decided to authorize his own user data to shopping application B, he can trigger the authorization control displayed on the client interface to instruct the client to generate an indication "allow The shopping app B gets the VC token of user A's user data".

Step 404, the client issues a VC token based on the DID of the user and the DID of the third-party application.

In this embodiment, the authorization of user data is implemented based on the DID. Therefore, in the issued VC token, the DID of each object actually represents the corresponding object.

Following the above example, assuming that the DID of user A is a1fdg4 and the DID of shopping application B is saff5d, then user A can be represented by a1fdg4 and shopping application B can be represented by saff5d in the VC token. Of course, in addition to the DIDs of the two, the scope of user data that user A opens to shopping application B can be further restricted. For example, the user data of user A may include: user name, nickname, instant messaging records, user avatar, user age and so on. However, in the VC token, it can be indicated that the shopping application B is only allowed to obtain the user name and user avatar.

Step 405, the client signs the VC token based on the identity private key of the third-party application.

In this embodiment, in order to facilitate the data provider to verify whether the VC token is issued to a third-party application after obtaining the VC token, in this step, the client can verify the VC token based on the identity private key of the third-party application. The token is signed.

Of course, in this step, the VC token can be further signed by the identity private key of the above-mentioned user A. Whether this step needs to be performed can be determined by those skilled in the art according to actual needs, which is not limited in this embodiment.

Step 406, the client sends the signed VC token to the authenticator.

In this embodiment, due to the timeliness of the VC token, the VC token can also be registered in the blockchain system, so that the blockchain system can maintain the status information used to indicate whether the VC token is valid .

Since in practical applications, the blockchain technology provider usually only allows the service party that has a cooperative relationship with it to interact with the blockchain system, therefore, in this embodiment, the VC token can be sent to the Provided by the authenticator, the authenticator generates a corresponding registration transaction to register the VC token into the blockchain system.

Step 407, the authenticator generates a registration transaction based on the signed VC token and sends it to the blockchain system.

Following the above examples, the blockchain system can directly register the VC token upon receiving it, or, in the case of the VC token being signed by user A’s identity private key, it can preferentially register the user according to the VC token. A's DID obtains the identity public key of user A stored on the chain to verify the VC token, and only if the verification is successful, then registers the VC token to the blockchain system and checks its status information is maintained. What needs to be declared is that the status information of the successfully registered VC token is marked as valid. If in the subsequent process, user A no longer authorizes the corresponding user data to shopping application B, he can send a revocation to the blockchain system. The transaction method changes the status information of the VC token to the revoked status. Of course, user A can also indicate the validity period of the VC token in the VC token in advance, then the blockchain system can periodically revoke the VC token after the registration is completed.

Step 408, the blockchain system registers the VC token, and marks the status information of the registered VC token as valid.

Step 409, the blockchain system returns the DID of the registered VC token to the authenticator.

In this embodiment, when the blockchain system registers the VC token, it can generate a DID corresponding to the VC token, so that the data provider can obtain the status information of the VC token according to the DID.

It should be understood that this embodiment only uses the DID of the VC token to obtain the status information of the VC token as an example. In actual operation, the blockchain system only needs to return the unique identification information corresponding to the VC token , that is, the status information can be obtained in the subsequent verification process. For example, the unique identification information can be the hash value of the VC token in addition to the DID of the VC token. What kind of identification is used to obtain the VC token in this embodiment? The status information of the card can be determined by those skilled in the art according to the actual situation, which is not limited in this embodiment.

Step 410, the authenticator returns the DID of the VC token to the client.

Step 411, the client generates a data acquisition request based on the signed VC token and the DID of the VC token.

In this embodiment, after the client receives the returned DID of the VC token, it can generate a data acquisition request based on the signed VC token and the DID, and send it to the data provider.

Step 412, the client sends a data acquisition request to the data provider.

In this embodiment, the data provider may be other data servers that are different from the authentication party and the blockchain system described above. The data provider verifies the VC token through the DID registered in the blockchain system, instead of following the authentication result of the authenticator.

Step 413, the data provider generates a verification voucher based on the DID of the third-party application and the DID of the VC token to obtain the transaction.

Following the above example, after obtaining the data acquisition request, the data provider can read the signed VC token and the DID of the VC token from the request, and further obtain the DID of the shopping application B from the VC token. On this basis, the identity public key of shopping application B can be obtained from the blockchain system based on the DID of shopping application B to verify whether the authorized party in the VC token is shopping application B; and based on the VC token DID obtains the status information of the VC token from the blockchain system to determine whether the VC token is valid.

Step 414, the data provider sends the verification certificate acquisition transaction to the blockchain system.

In this embodiment, both the state information of the VC token and the identity public key of the third-party application are used to verify the VC token. Therefore, both the state information of the VC token and the identity public key of the third-party application can be called as a verification certificate.

In actual operation, the data provider usually does not obtain the state information of the VC token and the identity public key of the third-party application through two interactions, but obtains the state information of the VC token and the identity of the third-party application through one interaction public key. Specifically, the data provider can generate a verification credential acquisition transaction based on the DID of the VC token and the DID of the third-party application, and send the verification credential acquisition transaction to the blockchain system.

Following the above example, a verification voucher transaction is generated based on the DID of the VC token and the DID of the shopping application B, and sent to the blockchain system.

Step 415, the blockchain system executes the verification credential acquisition transaction to obtain the identity public key of the third-party application according to the DID of the third-party application, and obtain the status information of the VC token according to the DID of the VC token.

Following the above example, after the blockchain system receives the above-mentioned verification certificate acquisition transaction, it can read the DID of the VC token and the DID of the shopping application B, and obtain the identity public key of the shopping application B according to the DID of the shopping application B 1. Obtain the state information of the VC token according to the DID of the VC token.

Step 416, the blockchain system returns the identity public key of the third-party application and the state information of the VC token to the data provider.

Step 417, the data provider verifies the VC token based on the identity public key of the third-party application, and determines whether the status information indicates that the VC token is valid; if the verification is successful and the VC token is valid, then go to step 418.

Following the above example, after receiving the status information of the VC token returned by the blockchain system and the identity public key of the shopping application B, the data provider can determine whether the VC token is valid according to the status information, and through the shopping application B B's identity public key verifies the signed VC token. If it is determined that the VC token is valid and the signature verification is successful, it proves that the shopping application B has the authority to obtain the user data indicated in the VC token, and the data provider can obtain the corresponding user data according to the indication in the VC token and return it to the client to be provided to the shopping application B by the client.

Step 418, the data provider returns the user data indicated in the VC token to the client.

It can be seen from the above technical solution that this embodiment can issue a VC token for a third-party application running in the client under the instruction of the user, so as to instruct the data provider to return the corresponding user data to the client through the VC token, and provided to third-party applications. It should be understood that this embodiment is equivalent to using the above-mentioned VC token as a data authorization credential to control the user data authorization process, which avoids the problem in the related art that the user cannot control the user data authorization process.

Further, in this embodiment, the VC token can be further registered in the blockchain system, so that the state data of the VC token can be maintained by the blockchain system. On this basis, the data provider can obtain the status information of the VC token through the blockchain system to determine whether the VC token is valid, thereby avoiding the problem of providing user data to third-party applications based on invalid VC tokens. Issues that lead to user data leakage.

The specification is described with reference to flowchart illustrations and/or block diagrams of methods, systems, and computer program products according to embodiments of the specification. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

Those skilled in the art should understand that one or more embodiments of this specification may be provided as a method, system or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. The form of the product.

One or more embodiments of this specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment. In the description of this specification, descriptions with reference to the terms "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features described in connection with the embodiment or example , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples and features of different embodiments or examples described in this specification without conflicting with each other.

The above description is only an example of one or more embodiments of this specification, and is not intended to limit one or more embodiments of this specification. For those skilled in the art, various modifications and changes may occur in one or more embodiments of this description. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims

A user data authorization method, comprising:

After receiving the user's authorization instruction, the client issues a verifiable statement based on the user's identity private key, the user's distributed digital identity information, and the distributed digital identity information of the target application in the client , the verifiable statement is used to indicate that the target application is allowed to obtain the user data of the user; and, the client sends a data acquisition request including the verifiable statement to the data provider, and the data acquisition request Or the verifiable statement contained in the data acquisition request is signed by the identity private key of the target application;

The data provider reads the verifiable statement from the received data acquisition request, and obtains the corresponding identity from the blockchain system according to the distributed digital identity information of the authorized party contained in the read verifiable statement The public key is used to verify the signature of the received data acquisition request or the read verifiable statement through the obtained identity public key, and if the signature verification is successful, the user data indicated in the read verifiable statement will be read returned to the client for provisioning to the target application.
The method according to claim 1,

The target application is a native application provided by the client's native server; or,

The target application is a third-party application provided by a third-party service provider different from the original service provider.
The method according to claim 1, when the client receives the user's authorization instruction, based on the user's identity private key, the user's distributed digital identity information and the target in the client Applied distributed digital identity information issues verifiable claims, including:

After receiving the authorization instruction from the user, the client determines the login status of the user;

If the user's login status is logged in, issue a verifiable statement based on the user's identity private key, the user's distributed digital identity information, and the distributed digital identity information of the target application in the client .
The method according to claim 3, further comprising:

When the client receives the user's login request, it initiates a login request to the authenticator based on the user's identity private key and distributed digital identity information;

The authenticator obtains the user's identity public key from the blockchain system based on the distributed digital identity information contained in the login request to verify the signature of the login request, and if the verification passes , returning login authorization information to the client;

After receiving the login authorization information, the client marks the login status of the user as logged in.
The method according to claim 1, further comprising:

The client registers the verifiable statement with the blockchain system, so that the state information of the verifiable statement is maintained by the blockchain system;

When the data provider receives the verifiable statement, it obtains the status information of the verifiable statement from the blockchain system, and when the status information indicates that the verifiable statement is valid and for If the verification of the verifiable statement is successful, the user data is returned to the client.
According to the method according to claim 5, the client registers the verifiable statement with the blockchain system, so that the state information of the verifiable statement is maintained by the blockchain system, including:

The client generates a registration request for the verifiable claim and sends it to the authenticator;

After receiving the registration request, the authenticator generates a registration transaction containing the verifiable statement and sends it to the blockchain system;

The blockchain system executes the registration transaction to deposit the received verifiable statement and maintain the status information of the verifiable statement.
The method according to claim 5, further comprising:

The client instructs the blockchain system to change the state information of the verifiable information to a revoked state when receiving the user's revocation request for the verifiable statement.
According to the method according to claim 1, the data acquisition request or the verifiable statement contained in the data acquisition request is also signed via the user's identity private key; the method further comprises:

After the data provider reads the verifiable statement, it obtains the corresponding identity public key from the blockchain system according to the distributed digital identity information of the authorized party contained in the read verifiable statement, to verify the signature of said verifiable statement;

The data provider returns the user data only when the signature verification operation based on the identity public key of the authorizer and the signature verification operation based on the identity public key of the authorized party pass. to the client.
According to the method according to claim 1, the data provider is a data server different from the blockchain system, or is the blockchain system.
The method according to claim 1, further comprising:

The client sends the verifiable statement to the transit server;

The transit server determines the data server storing the user data from among several data servers included in the data network according to the distributed digital identity information of the user, and uses the determined data server as the data provider.
The method according to claim 1, said method further comprising:

The data provider acquires the stored first data about the user as the user data; or,

The data provider acquires the stored second data about the user, and processes the second data according to the instruction of the verifiable statement, so as to use the processing result as the user data.
The method according to claim 11, wherein the data provider processes the second data according to the instruction of the verifiable statement, so as to use the processing result as the user data, comprising:

The data provider encrypts the second data based on the trusted execution environment identity public key indicated in the verifiable statement in the case that the verifiable statement indicates that the second data needs to be securely calculated transmission, and input the encrypted second data into the corresponding trusted execution environment, so that after the trusted execution environment decrypts the encrypted second data based on its own identity private key, according to the verifiable statement Instructed pre-deployed computing tasks to perform secure computations;

The data provider uses the secure calculation result generated by the trusted execution environment as the user data.
The method according to claim 12, wherein said second data is encrypted and transmitted based on the trusted execution environment identity public key indicated in said verifiable statement, and the encrypted second data is input into the corresponding trusted In the execution environment, after the trusted execution environment decrypts the encrypted second data based on its own identity private key, the secure computing is performed according to the pre-deployed computing tasks indicated by the verifiable statement, including:

The data provider encrypts the second data based on the identity public key of the on-chain trusted execution environment indicated in the verifiable statement, and based on the encrypted second data and the Included calculation tasks generate secure calculation transactions;

In the case of receiving the secure computing transaction, the privacy blockchain executes the secure computing transaction in the on-chain trusted execution environment maintained by itself, so as to pass the identity private key pair of the on-chain trusted execution environment After the second data is decrypted, a pre-deployed smart contract for completing the calculation task is invoked to perform secure calculation on the decrypted second data.
A user data authorization system, including a client and a data provider; wherein,

When the client receives the user's authorization instruction, it issues an available license based on the user's identity private key, the user's distributed digital identity information, and the distributed digital identity information of the target application in the client. A verification statement, where the verifiable statement is used to indicate that the target application is allowed to obtain the user data of the user; and, the client sends a data acquisition request including the verifiable statement to the data provider, and the The data acquisition request or the verifiable statement contained in the data acquisition request is signed by the identity private key of the target application;

The data provider reads the verifiable statement from the received data acquisition request, and obtains the corresponding distributed digital identity information of the authorized party contained in the read verifiable statement from the blockchain system. The identity public key is used to verify the signature of the received data acquisition request or the read verifiable statement through the obtained identity public key, and if the verification is successful, the read verifiable statement User data is returned to the client for provision to the target application.