A data usage authorization method, system and apparatus

Abstract

The specification discloses a data use authorization method, system and device. The method comprises: in response to a use authorization instruction of a target data from an authorized party, using an authorized party private key corresponding to an authorized party public key to digitally sign a signature object; the signature object comprises the target data; generating a first verifiable claim comprising an authorized party DID identifier, a digital signature and the signature object as a use authorization credential issued by the authorized party; the step of verifying whether the first verifiable claim is generated by the authorized party device comprises: determining the authorized party public key corresponding to the authorized party DID identifier in the first verifiable claim through a blockchain network, verifying the digital signature in the first verifiable claim using the authorized party public key, and determining that the first verifiable claim is generated by the authorized party device when the digital signature is verified to be correct; and sending the first verifiable claim to a use demand party device through a direct connection between the authorized party device and the use demand party device.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of blockchain technology, and more particularly to a method, system, and device for data usage authorization. Background Art

[0002] Currently, when businesses conduct business for users, they usually need to obtain user authorization to use the data to be authorized before they can use the data to be authorized. The data to be authorized may include: the user's private information, information credentials, or identity information.

[0003] However, in many scenarios, network factors often make user authorization difficult, hindering business operations. For example, in offline scenarios or scenarios with poor network signals, data exchange between users and business parties is difficult, making user authorization impossible. Alternatively, in monitored network scenarios, such as local area networks, the data to be authorized is important and private, and users may not want to transmit it over such a monitored network. Summary of the Invention

[0004] To solve the above technical problems, the embodiments of this specification provide a data usage authorization method, system, and device. The technical solution is as follows.

[0005] A data use authorization method is applied to an authorizer device; a distributed digital identity (DID) is pre-registered for the authorizer on a blockchain network so that the blockchain network stores a correspondence between the authorizer's DID and the authorizer's public key; the method comprises:

[0006] In response to an authorization instruction from an authorized party to authorize the use of target data, digitally sign a signature object using a private key of the authorized party corresponding to a public key of the authorized party; the signature object includes the target data;

[0007] Generate a first verifiable statement including the authorizer DID, the digital signature, and the signature object as a use authorization certificate issued by the authorizer; wherein the step of verifying whether the first verifiable statement is generated by the authorizer device includes: determining, through the blockchain network, the authorizer public key corresponding to the authorizer DID in the first verifiable statement, using the authorizer public key to verify the digital signature in the first verifiable statement, and if the digital signature is verified successfully, determining that the first verifiable statement was generated by the authorizer device;

[0008] The first verifiable statement is sent to the user requester device through a direct connection with the user requester device, so that the user requester device obtains authorization to use the target data.

[0009] A data use authorization method, wherein a blockchain network pre-registers a distributed digital identity (DID) for an authorizer, so that the blockchain network stores a correspondence between the authorizer's DID identifier and the authorizer's public key;

[0010] The method comprises:

[0011] The authorizing party device responds to the authorizing party's instruction to authorize the use of the target data by using the authorizing party's private key corresponding to the authorizing party's public key to digitally sign the signature object; the signature object includes the target data;

[0012] The authorizing party device generates a first verifiable statement including the authorizing party DID, the digital signature, and the signature object as a use authorization certificate issued by the authorizing party; wherein the step of verifying whether the first verifiable statement is generated by the authorizing party device includes: determining, through the blockchain network, the authorizing party public key corresponding to the authorizing party DID in the first verifiable statement, using the authorizing party public key to verify the digital signature in the first verifiable statement, and determining that the first verifiable statement is generated by the authorizing party device if the digital signature is verified successfully;

[0013] The authorizing device sends the first verifiable statement to the user requesting device through a direct connection between the authorizing device and the user requesting device;

[0014] The user obtains the first verifiable statement using the demander device to obtain authorization to use the target data.

[0015] A data use authorization device is applied to an authorizer device; a distributed digital identity (DID) is pre-registered for the authorizer on a blockchain network, so that the blockchain network stores the corresponding relationship between the authorizer DID identifier and the authorizer public key;

[0016] The device comprises:

[0017] a response unit, configured to digitally sign a signature object using a private key of the authorizer corresponding to the public key of the authorizer in response to an authorization instruction of the authorizer for use of the target data; the signature object includes the target data;

[0018] a generating unit, configured to generate a first verifiable statement including the authorizing party DID, the digital signature, and the signature object, as a use authorization certificate issued by the authorizing party; wherein the step of verifying whether the first verifiable statement was generated by the authorizing party device comprises: determining, through the blockchain network, the authorizing party public key corresponding to the authorizing party DID in the first verifiable statement, using the authorizing party public key to verify the digital signature in the first verifiable statement, and determining that the first verifiable statement was generated by the authorizing party device if the digital signature is verified successfully;

[0019] The sending unit is configured to send the first verifiable statement to the user demand side device through a direct connection with the user demand side device, so that the user demand side device obtains authorization to use the target data.

[0020] A data use authorization system, wherein a blockchain network pre-registers a distributed digital identity (DID) for an authorizer, so that the blockchain network stores the correspondence between the authorizer's DID identifier and the authorizer's public key;

[0021] The system includes an authorization party device and a user demand party device;

[0022] The authorizing party device is used to: respond to the authorizing party's authorization instruction for use of the target data, digitally sign the signature object using the authorizing party's private key corresponding to the authorizing party's public key; the signature object includes the target data; generate a first verifiable statement including the authorizing party's DID identifier, the digital signature and the signature object as a use authorization certificate issued by the authorizing party; wherein the step of verifying whether the first verifiable statement is generated by the authorizing party device includes: determining the authorizing party's public key corresponding to the authorizing party's DID identifier in the first verifiable statement through the blockchain network, using the authorizing party's public key to verify the digital signature in the first verifiable statement, and if the digital signature is verified, determining that the first verifiable statement is generated by the authorizing party device; and sending the first verifiable statement to the user demander device through a direct connection with the user demander device;

[0023] The user demander device is used to obtain the first verifiable statement to obtain authorization to use the target data.

[0024] In the above technical solution, the authorizing device can generate a first verifiable statement as an authorization certificate for the use of the target data. Through a direct connection with the user's device, the first verifiable statement can be transmitted to the user's device to complete the data use authorization without the help of a network, so that the data use authorization will not be affected by network factors. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this specification. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0026] Figure 1 This is a flowchart of a data use authorization method provided in an embodiment of this specification;

[0027] Figure 2 This is a flowchart of another data use authorization method provided in an embodiment of this specification;

[0028] Figure 3 This is a schematic diagram of the principle of a data use authorization method provided in an embodiment of this specification;

[0029] Figure 4 This is a schematic diagram of the principle of a network monitoring stage provided by an embodiment of this specification;

[0030] Figure 5 This is a structural diagram of a data use authorization system provided in an embodiment of this specification;

[0031] Figure 6 This is a structural diagram of a data use authorization device provided in an embodiment of this specification;

[0032] Figure 7 It is a structural diagram of a device used to configure the method of the embodiment of this specification. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the technical solutions in the embodiments of this specification will be described in detail below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art should fall within the scope of the disclosure.

[0034] Currently, when businesses conduct business for users, they usually need to obtain user authorization to use the data to be authorized before they can use the data to be authorized. The data to be authorized may include: the user's private information, information credentials, or identity information.

[0035] For example, when a user watches an offline performance, he or she can use a portable mobile terminal to authorize the gate machine to use the user's information credentials. The information credentials can specifically be tickets for offline performances. The gate machine can open after verifying the information credentials, making it convenient for the user to enter the venue; when the user wants to enter a shopping mall, for the purpose of security management, he or she can use a portable mobile terminal to authorize the mall equipment to use some of the user's private information, which can specifically include the user's itinerary information. The mall equipment can allow the user to enter the mall after verifying the privacy information.

[0036] However, in many scenarios, network factors often make user authorization difficult, hindering business operations. For example, in offline scenarios or scenarios with poor network signals, data exchange between users and business parties is difficult, making user authorization impossible. Alternatively, in monitored network scenarios, such as local area networks, the data to be authorized is important and private, and users may not want to transmit it over such a monitored network.

[0037] In order to solve the above technical problems, an embodiment of this specification provides a data usage authorization method.

[0038] Simply put, in the method provided in the embodiments of this specification, the data usage authorization process can be limited to the authorizing party issuing a usage authorization certificate for the target data (that is, the data to be authorized) to the user requesting the data. Through the verifiable usage authorization certificate, the user requesting the data can prove that its use of the target data is authorized by the authorizing party. Specifically, it can be done by verifying that the usage authorization certificate is issued by the authorizing party for the use of the target data.

[0039] Since the authorization process only requires the transmission of the authorization credential, a direct connection can be established between the authorizer's device and the user's device to avoid network interference. This direct connection eliminates the need for a third party, and therefore the network, to transmit the authorization credential. This eliminates the need for network transmission and improves data transmission security, reducing the likelihood of authorization credential leakage during data transmission. This eliminates the impact of network interference and facilitates business operations.

[0040] Specifically, this method utilizes a blockchain network to decentrally store the authorized party's distributed digital identity (DID) and the public key created by the authorized party (referred to as the authorized party's public key for ease of description). By storing the correspondence between the authorized party's DID and public key on the blockchain network, the possibility of tampering with the authorized party's DID and public key can be reduced, and the authorized party's DID and public key can be used for subsequent signature verification.

[0041] In this method, the authorizing party may grant the use rights of the target data to the user who requests the data.

[0042] Specifically, the authorizer device may digitally sign the signature object containing the target data using the authorizer private key corresponding to the authorizer public key according to the authorizer's authorization instruction for the target data.

[0043] Afterwards, a first verifiable statement including the authorized party's DID, the signature object, and the digital signature may be generated. The generated first verifiable statement may serve as a usage authorization certificate issued by the authorized party.

[0044] Finally, the authorizing device sends the generated first verifiable statement to the user device, completing the authorization of the target data. The user device can also use the target data in the obtained first verifiable statement to conduct business.

[0045] Once the user acquires the generated first verifiable statement, it is equivalent to obtaining a use authorization certificate issued by the authorizing party. Obtaining the use authorization certificate represents authorization to use the target data. In other words, after obtaining the first verifiable statement, the user can legally use the target data based on the authorization.

[0046] This authorization certificate can also be used for subsequent verification to prove to other parties (such as regulators) that the use of the target data is authorized by the authorized party, rather than illegal use of the target data or direct use of the target data without authorization.

[0047] The verification of the first verifiable statement (using the authorization certificate) can specifically be performed on the digital signature in the first verifiable statement. The corresponding authorizer public key can be queried in the blockchain network through the authorizer DID identifier in the first verifiable statement, and the digital signature can be verified using the authorizer public key.

[0048] If verification succeeds, it means that the digital signature must have been generated based on the authorized party's private key, thereby proving that the first verifiable statement must have been issued by the authorized party (because only the authorized party holds the authorized party's private key). If verification fails, it cannot be proved that the first verifiable statement was issued by the authorized party. In the event of a verification failure, the failure may be caused by a variety of reasons, such as the signature object in the first verifiable statement being tampered with or the digital signature in the first verifiable statement object being incorrect.

[0049] Therefore, the first verifiable statement, acting as a credential for authorization, can be easily verified based on the public key of the authorizer in the blockchain network to verify that the authorization credential was generated by the authorizer. Furthermore, the first verifiable statement can be used as a credential for authorization and verified at any time after authorization, ensuring that the use of the target data is authorized by the authorizer.

[0050] In this method, because network factors must be avoided, a direct connection can be established between the authorizing party's device and the user's device. Specifically, a direct connection can be one without the involvement of a third party. This eliminates the need to rely on a network to transmit the first verifiable claim. Furthermore, it improves data transmission security, reducing the likelihood of leakage of the first verifiable claim during data transmission. This eliminates the impact of network factors and facilitates business operations.

[0051] It is understandable that since a direct connection does not involve a third party, it does not include any network connection. Network connections, such as wired network connections and wireless network connections, usually involve multiple forwarding devices for forwarding, which obviously does not meet the definition of a direct connection. Therefore, the influence of network factors can be avoided through direct connection.

[0052] Optionally, a direct connection may be established directly through near field communication, or a direct connection between devices may be established using Bluetooth, a direct wired connection, or the like.

[0053] Furthermore, since the first verifiable statement also includes the target data, the target data can be sent to the user along with the first verifiable statement. This allows the user to obtain the target data while obtaining authorization to use the target data, thereby improving data transmission efficiency.

[0054] Of course, the first verifiable statement may also include other content. Specifically, it may include other content in the signature object, optionally including the authorizer's DID, an authorization serial number used to identify the current authorization, the requester's ID, the requester's device ID, validity period information, authorization time information, etc. The digital signature can verify the correctness and completeness of each content in the signature object and can also facilitate more detailed verification.

[0055] Optionally, the signature object may include the user demander's device identifier to ensure that the generated first verifiable statement is generated for a single user demander's device. Obviously, other devices cannot use the first verifiable statement as a usage authorization credential.

[0056] Therefore, optionally, the specific process of verifying the first verifiable statement may further include verifying whether the device information included in the signature object in the first verifiable statement matches the device of the user demander.

[0057] In a specific application embodiment, for example, when a user watches an offline performance, a portable mobile terminal can be used to digitally sign the user's information credential (ticket) using the user's private key to generate an authorization verifiable statement containing the digital signature, information credential, and user DID identifier. In an offline scenario or a scenario with a poor network, the user can use the mobile terminal to send the generated authorization verifiable statement directly to the gate through near-field communication. The gate can verify the information credential (ticket) in the authorization verifiable statement. If the information credential is verified, the gate can be opened to facilitate the user's entry. The gate needs to retain the authorization verifiable statement as an authorization credential for conducting business to verify the information credential, so that in the subsequent scenario connected to the network, the gate can self-check, or when the subsequent regulatory authorities need to supervise whether the gate is using the information credential legally, the authorization verifiable statement can be presented to prove that the gate is authorized by the user.

[0058] Therefore, in a data usage authorization method provided in an embodiment of this specification, the authorizing device can transmit the first verifiable statement to the user requesting party through a direct connection between the authorizing device and the user requesting party, thereby realizing the data usage authorization process without the participation of a third party in the transmission, and thus will not be affected by network factors.

[0059] The above method can be used in a variety of network environments, regardless of network availability. For example, offline scenarios, scenarios with poor network signals, and monitored network scenarios. It can also achieve data use authorization without the need for a network, and provide proof of authorization intent. It can also reduce the possibility of data leakage due to network transmission and improve data transmission security.

[0060] The following further explains a data use authorization method provided in this specification with reference to the accompanying drawings.

[0061] It should be noted that since this method involves interaction between devices, for ease of description and distinction, the two interacting devices are referred to as the authorizer device and the user device. In this method, the authorizer device can grant the user device permission to use the target data, and the user device can use the target data to conduct business.

[0062] The authorizing party device can be a user device used to perform data authorization. The demanding party device can be a service-side device used to obtain target data authorized by the authorizing party to conduct business. Of course, the demanding party device can also be another user device used to obtain target data authorized by the authorizing party to conduct business.

[0063] Furthermore, in an optional embodiment, the authorizer device and the requester device may have the capability of establishing a direct connection between each other without the involvement of a third party.

[0064] The direct connection can specifically be a short-range communication connection. The authorizing party device and the user demanding party device can have a short-range communication module to facilitate the establishment of a short-range communication channel. For example, the short-range communication can be Bluetooth, and the authorizing party device and the user demanding party device both need to have Bluetooth functionality to facilitate the use of Bluetooth to establish a short-range communication channel. The short-range communication can also be Near Field Communication (NFC), and the authorizing party device and the user demanding party device both need to have an NFC function module to facilitate communication through the NFC function module.

[0065] like Figure 1 FIG2 is a flow chart of a data usage authorization method provided in an embodiment of this specification. The method can be applied to an authorization party device.

[0066] The blockchain network can pre-register a distributed digital identity (DID) for the authorizer, allowing the blockchain network to store the correspondence between the authorizer's DID and its public key. Alternatively, the blockchain network can store multiple sets of DID and public key correspondences. The authorizer's public key can be a public key created by the authorizer's device, which can be used to register the authorizer's DID. The specific process for registering a DID is explained later.

[0067] The method may include at least the following steps.

[0068] S101: In response to an authorization instruction from an authorized party to authorize the use of target data, a signature object is digitally signed using a private key of the authorized party corresponding to a public key of the authorized party.

[0069] Optionally, the signature object may include target data. Of course, in other optional embodiments, the signature object may also include other content.

[0070] S102: Generate a first verifiable statement including the authorized party's DID, digital signature, and signature object as a usage authorization certificate issued by the authorized party.

[0071] Optionally, the step of verifying whether the first verifiable statement was generated by the authorized party device includes: determining, through the blockchain network, the authorized party public key corresponding to the authorized party DID identifier in the first verifiable statement, and using the authorized party public key to verify the digital signature in the first verifiable statement. If the digital signature verification succeeds, it can be determined that the first verifiable statement was generated by the authorized party device. If the digital signature verification fails, it can be determined that the first verifiable statement was not generated by the authorized party device.

[0072] S103: Send the first verifiable statement to the user demand side device through a direct connection with the user demand side device, so that the user demand side device obtains authorization to use the target data.

[0073] Optionally, a direct connection can be established directly between the authorizing party's device and the user's device without the involvement of a third party. Specifically, it can be a direct connection between devices at close range, including near-field communication, Bluetooth, and direct data cable connections. Direct connections do not include connections involving intermediaries such as wired or wireless networks.

[0074] In the above method process, the authorizing party device can transmit the first verifiable statement that can be used to prove that the user is legally using the target data (that is, using the target data after obtaining the authorization from the authorizing party) to the user through a direct connection with the user's device, thereby realizing the data usage authorization process without the participation of a third party in the transmission, and will not be affected by network factors, thereby facilitating subsequent business operations.

[0075] The following is a detailed explanation of each step.

[0076] 1. The following is an explanation of S101.

[0077] S101: In response to an authorization instruction from an authorized party to authorize the use of target data, a signature object is digitally signed using a private key of the authorized party corresponding to a public key of the authorized party.

[0078] Optionally, the signature object may include target data.

[0079] 1. Use authorization instructions and identity authentication for the authorized party.

[0080] In an optional embodiment, the authorizer can trigger an authorization instruction for the use of the target data by operating the authorizer's device, so that the authorizer's device can grant the use rights of the target data to other devices, facilitating the other devices' legal use of the target data. This method does not limit the triggering method and specific form of the authorization instruction for the use of the target data.

[0081] It should be noted that, since the authorizing party device can usually be operated by other users, the use authorization instruction may be triggered by other users. In order to improve the security of authorization, it is necessary to ensure that the authorizing party device is operated by the authorizing party with authorization authority.

[0082] Therefore, after the use authorization instruction is actually triggered, or before the use authorization instruction is actually triggered, the identity of the authorizer can be authenticated. After the identity of the authorizer is confirmed, it can be determined that the use permission of the target data can be granted to other devices, so that subsequent steps can be further performed.

[0083] In an optional embodiment, the specific use authorization instruction may be triggered only after the authorizer has passed identity authentication. Alternatively, in response to the authorizer's use authorization instruction for the target data, the authorizer may be authenticated before the signature object is digitally signed. Only after the authorizer has passed identity authentication can the signature object be digitally signed and subsequent authorization processes be executed.

[0084] Optionally, the target data usage authorization instruction is triggered when the authorized party passes identity authentication.

[0085] Optionally, digitally signing the signature object using the authorized party's private key corresponding to the authorized party's public key may include: performing identity authentication on the authorized party; and when it is determined that the authorized party has passed the identity authentication, digitally signing the signature object using the authorized party's private key corresponding to the authorized party's public key.

[0086] This embodiment does not limit the specific identity authentication method, as long as it can be determined that the identity of the authorizer has the authorization authority to use the target data.

[0087] As an exemplary explanation, optionally, identity authentication can be performed through authentication methods such as password authentication, fingerprint authentication, face authentication, gesture authentication, etc.

[0088] Optionally, after the authorized party enters the password to be authenticated, the password can be authenticated to determine whether it is the same as a pre-stored password. The pre-stored password can be a password pre-stored by a user with authorization to use the target data. If the password to be authenticated is the same as the pre-stored password, the authorized party can be determined to have passed identity authentication.

[0089] Alternatively, authentication can be performed using biometric features, such as fingerprints, pupils, or faces. The authorizing party's device can collect the authorizing party's biometric features to be authenticated and compare them with pre-stored biometric features. Pre-stored biometric features can be pre-stored biometric features of a user with authorized access to the target data. If the similarity between the biometric features to be authenticated and the pre-stored biometric features reaches a preset threshold, the authorizing party can be determined to have successfully passed identity authentication.

[0090] In summary, the identity information to be authenticated of the authorized party can be obtained, and then the identity information to be authenticated is matched with the preset identity information to determine whether the match is successful. If it is determined that the identity information to be authenticated matches the preset identity information, it can be determined that the authorized party has passed the identity authentication.

[0091] The preset identity information may be pre-stored identity information of a user with authorization to use the target data, and may specifically be the identity information of the user with authorization to use the target data, or the identity information of another user. The user with authorization to use the target data may specify other users who can also authorize use of the target data.

[0092] The specific matching process is not limited in this embodiment, and can be determined based on the degree of overlap between the identity information to be authenticated and the preset identity information. Optionally, the identity information to be authenticated of the authorized party can be obtained and then compared with the preset identity information. If it is determined that the degree of overlap between the identity information to be authenticated and the preset identity information is greater than or equal to a preset overlap threshold, it can be determined that the authorized party has passed identity authentication.

[0093] The matching process can be specifically determined based on the type of identity information. Optionally, if the identity information is a password, the matching process can be limited to comparing the input password to be authenticated with the preset password to see if they are the same. If the password to be authenticated and the preset password are the same, the match can be determined to be successful. Of course, the preset coincidence threshold can be set to 100%.

[0094] When the identity information is a biometric, since the biometric may change during the collection process or may change slightly over time, the matching process can be limited to comparing the similarity between the input biometric to be authenticated and the preset biometric to see whether it reaches a preset similarity threshold. If the similarity between the biometric to be authenticated and the preset biometric reaches the preset threshold, the match can be determined to be successful. Of course, similarity can be regarded as overlap, and the preset similarity threshold can be regarded as a preset overlap threshold.

[0095] In the process of identity authentication for the authorized party, the authorized party's device needs to store preset identity information to facilitate identity authentication.

[0096] In order to improve the security of identity authentication, in an optional embodiment, a trusted execution environment (TEE) can be deployed in the authorized party's device. The trusted execution environment is a closed, independent operating environment in which the data stored or run is usually not leaked outside the trusted execution environment. Data can only be input or output operating results can be obtained through the interface of the trusted execution environment. Therefore, data can be stored in the trusted execution environment to improve data security, and programs can also be run through the trusted execution environment to improve the security of program operation.

[0097] Therefore, optionally, the preset identity information can be stored in the TEE of the authorizing device to improve the security of the preset identity information. The identity authentication process can also be performed in the TEE of the authorizing device to improve the security of the identity authentication.

[0098] In an optional embodiment, the authorizing party device may have a trusted execution environment TEE, which stores preset identity information; performing identity authentication specifically for the authorizing party may include: obtaining the authorizing party's identity information to be authenticated into the TEE; judging in the TEE whether the identity information to be authenticated successfully matches the preset identity information; and determining that the authorizing party has passed the identity authentication when it is determined that the identity information to be authenticated successfully matches the preset identity information.

[0099] Optionally, obtaining the identity information to be authenticated of the authorized party may be based on an operation of the authorized party, obtaining the identity information to be authenticated input by the authorized party, such as password information, or may be based on collecting the identity information to be authenticated of the authorized party, such as biometric information.

[0100] In a specific example, the authorizing device can collect the authorizing party's fingerprint information to be authenticated and store it in the authorizing device's TEE. The TEE stores reserved fingerprint information, which is fingerprint information stored by users with authorization permissions. The TEE can further compare the similarity between the fingerprint information to be authenticated and the reserved fingerprint information. If the similarity is greater than or equal to a preset similarity threshold, the authorization process for the target data can be executed. Specifically, this can trigger an authorization instruction for the target data or allow the digital signature of the signature object to continue.

[0101] In this embodiment, by authenticating the authorized party, the security of the target data use authorization can be improved. By implementing identity authentication in TEE, the security of identity authentication and target data use authorization can be further improved, and the data in the identity authentication process can be protected from being leaked from the TEE.

[0102] Of course, optionally, the subsequent digital signature process can also be executed in TEE to improve the security of the digital signature process.

[0103] 2. Digital signature.

[0104] In an optional embodiment, in response to the use authorization instruction, the use authorization process of the target data can be executed. Of course, the use authorization process of the target data can also be executed after the authorizing party passes the identity authentication.

[0105] Optionally, in the present method, the target data use authorization process may include performing a digital signature, generating a first verifiable statement, and sending the first verifiable statement to the user's device. The first verifiable statement will be explained later.

[0106] The digital signature can be used to prove that the digital signature was generated by the authorized party's device, thereby proving the authorized party's authorization to use the target data.

[0107] Specifically, a digital signature can be created using the authorized party's private key corresponding to the authorized party's public key, allowing for subsequent verification of the signature using the authorized party's public key. The authorized party's private key and the authorized party's public key can be a pair of asymmetric encryption keys. Ciphertext encrypted using the authorized party's private key can be decrypted using the authorized party's public key.

[0108] Furthermore, digital signatures can also ensure the correctness and integrity of the signed object. If the signed object has been tampered with or is missing some content, then the digital signature will obviously not be verified.

[0109] In an optional embodiment, the signature object corresponding to the digital signature may include target data.

[0110] It should be noted that the signature object includes target data. When the correctness and integrity of the signature object are determined by the digital signature, the correctness and integrity of the target data can be determined, so as to facilitate the transmission of correct and complete target data to the device of the user for use.

[0111] In an optional embodiment, the target data may be data that the user needs to use, or may be data that the authorizer needs to authorize the user to use.

[0112] Optionally, the target data may include data required by the user to conduct business, such as the personal information, identity information, privacy information, electronic credentials, etc. of the authorized party.

[0113] This embodiment does not limit how the user uses the target data.

[0114] In an optional embodiment, the user may verify the target data, and therefore, the target data may include business data that can be verified.

[0115] Optionally, the target data may include business data and a digital signature for the business data, and the digital signature can be verified using the demander's device. It should be noted that the digital signature included in the target data is different from the digital signature generated for the signature object using the authorized party's private key.

[0116] In a specific example, the target data may include an electronic certificate and a digital signature for the electronic certificate. The digital signature for the electronic certificate may be obtained based on the private key of the authority, that is, the authority signs the electronic certificate using the authority's private key. Since the authority's public key may be public, the demander's device may store the authority's public key in advance so that the signature can be verified later without a network connection. Specifically, the demander's device may use the authority's public key to verify the digital signature in the target data, confirming that the electronic certificate has been authenticated by the authority's signature, thereby confirming that the target data has passed verification.

[0117] The electronic certificate can be an electronic version of an offline ticket. After the demander's device confirms that the electronic certificate has been authenticated by an authoritative party, the gate can be opened to allow the authorized party to enter.

[0118] Furthermore, this method does not limit the method for acquiring the target data. As an example, the target data may be pre-stored locally on the authorizing party's device, acquired in real time from another device, collected in real time based on the authorizing party's operation, or acquired in real time based on the authorizing party's input.

[0119] Optionally, the authorizer device can pre-store the target data. Specifically, the target data can be pre-acquired business data or pre-stored private information of the authorizer, allowing the authorizer device to directly retrieve the target data from local storage and digitally sign it. Since digital signatures can be executed in the authorizer device's TEE, the target data can also be pre-stored in the authorizer device's TEE, thereby improving the security of the target data and facilitating digital signatures.

[0120] Optionally, the authorizer's device can also obtain target data in real time. The target data can be data that requires real-time input from the authorizer, such as the authorizer's name, the account number the authorizer needs to log in to, or text information typed by the authorizer. It can also be data that requires real-time collection from the authorizer, such as the authorizer's facial information, fingerprint information, or gesture information. Therefore, based on the authorizer's operation, the authorizer's device can obtain the data input by the authorizer in real time as target data, or collect the authorizer's data in real time as target data.

[0121] Of course, since digital signatures can be executed in the TEE of the authorizer's device, the target data acquired in real time can also be acquired in the TEE of the authorizer's device to facilitate subsequent digital signatures for the target data.

[0122] In an optional embodiment, the signature object may also include the DID of the authorizing party. The method for obtaining the DID of the authorizing party is described in the explanation of S102 below.

[0123] It should be noted that the signature object includes the authorized party's DID identifier, and the correctness and integrity of the authorized party's DID identifier can be determined when the correctness and integrity of the signature object are determined by the digital signature.

[0124] In an optional embodiment, the authorizer DID identifier can be obtained by the authorizer after registering the DID, which is used to uniquely identify the authorizer in the blockchain network. The specific process of registering the DID is explained below.

[0125] After the authorizer registers the DID, the blockchain network can store the correspondence between the authorizer's DID and the authorizer's public key. Therefore, the corresponding authorizer's public key can be queried based on the authorizer's DID through the blockchain network to facilitate verification of the digital signature obtained in S101.

[0126] The blockchain network can try to ensure that the correspondence between the authorized party's DID identifier and the authorized party's public key is not tampered with, and has a high degree of trust.

[0127] Among them, the authorized party's DID identification can be used as a basis for querying the public key from the blockchain network, which is convenient for verifying the digital signature obtained in S101. On the other hand, it can also facilitate the determination of the authorized party who authorizes the use of the target data.

[0128] In an optional embodiment, the signature object may include not only the target data but also other content, specifically information indicating authorization to use the target data.

[0129] Optionally, the signature object may also include at least one of the following: the authorizing party DID identifier, the user requesting party identifier, the user requesting party device identifier, the first verifiable declaration identifier, the validity period, the specified usage rights of the target data, and the authorization time information, etc.

[0130] The user requester identifier can be used to identify the user requester who is granted permission to use the target data. The user requester identifier can specifically be the DID identifier of the user requester. The user requester can obtain the DID identifier in the same way as the authorizer.

[0131] The demander's device identifier can be used to identify the device that is granted the target data usage permission. The demander's device identifier can specifically be the physical address of the device.

[0132] The first verifiable declaration identifier may be used to represent the first verifiable declaration that the authorized party needs to generate subsequently. The first verifiable declaration identifier may specifically be the first verifiable declaration serial number generated by the authorized party.

[0133] The validity period can be used to indicate the limited period of authorization for the use of target data by the authorizer. After the validity period expires, the authorization for use of target data becomes invalid and the user's device should no longer use or store the target data.

[0134] The designated usage rights of target data can be used to represent the partial rights that the authorizer device has designated for the use of the target data by the demander device. For example, the authorizer device can specify that the target data can only be used locally on the demander device and cannot be sent out. In other words, the authorizer only grants the demander device "local usage rights" and not "send rights" for the target data. Alternatively, the authorizer device can specify that the target data can only be used for verification on the demander device and cannot be modified. In other words, the authorizer only grants the demander device "verification rights" and not "modification rights" for the target data.

[0135] The authorization time information can be used to represent the time point when the authorizer authorizes the use of the target data.

[0136] Of course, the signature object may also include other content, and this embodiment is only used for illustrative purposes. By using a digital signature, the correctness and integrity of each other content in the signature object can be easily verified.

[0137] For example, when the signature object contains the authorized party's DID identifier, it is convenient to verify the correctness and integrity of the authorized party's DID identifier, thereby facilitating the search for the correct authorized party's public key and increasing the possibility of successful subsequent digital signature verification.

[0138] In addition, some of the other contents can also help verify the first verifiable claim in other aspects besides "whether the first verifiable claim was generated by the authorized party device." The details will be explained later.

[0139] This embodiment does not limit the method for obtaining other content in the above-mentioned signature object. As an exemplary illustration, the use demander identifier can be obtained by the authorization party device from the use demander device. Specifically, the authorization party device can establish a direct connection with the use demander device. Through the direct connection, the use demander device sends the use demander identifier to the authorization party device, which is convenient for obtaining the signature object for signing and also convenient for generating the first verifiable statement later.

[0140] 2. The following is an explanation of S102.

[0141] S102: Generate a first verifiable statement including the authorized party's DID, digital signature, and signature object as a usage authorization certificate issued by the authorized party.

[0142] The digital signature is the digital signature obtained in S101, and the signature object is the signature object in S101.

[0143] Among them, optionally, the step of verifying whether the first verifiable statement is generated by the authorized party device includes: determining the authorized party public key corresponding to the authorized party DID identifier in the first verifiable statement through the blockchain network, using the authorized party public key to verify the digital signature in the first verifiable statement, and if the verification of the digital signature passes, determining that the first verifiable statement is generated by the authorized party device.

[0144] If the digital signature verification fails, it can be determined that the first verifiable statement is not generated by the authorized device.

[0145] 1. DID registration process and authorized party DID identification.

[0146] It should be emphasized that since the generation of the first verifiable statement requires the authorized party's DID, it is necessary to clarify the method for obtaining the authorized party's DID.

[0147] In an optional embodiment, the blockchain network has pre-registered the DID for the authorizer and stored the correspondence between the authorizer's DID and the authorizer's public key. Therefore, the authorizer's device can optionally obtain the authorizer's DID from the blockchain network, or the blockchain network can proactively issue the authorizer's DID to the authorizer's device. Specifically, after the blockchain network successfully pre-registers the authorizer's DID, the blockchain network issues the authorizer's DID to the authorizer's device.

[0148] Regarding DID registration, in an optional embodiment, the authorizer device can create a public-private key pair and submit a DID registration request to the blockchain network, including the authorizer public key. Based on the authorizer public key created by the authorizer device, the blockchain network can generate the authorizer DID, store the correspondence between the authorizer DID and the authorizer public key, and return the generated authorizer DID to the authorizer device.

[0149] Among them, optionally, the blockchain network generates the authorizer DID identification based on the authorizer public key created by the authorizer device, which may include: the blockchain network performs two hashing operations based on the authorizer public key, specifically the sha256 hash algorithm and the ripemd160 hash algorithm, and then converts it using the base58 encoding method to generate the authorizer DID identification that is unique to the authorizer device.

[0150] Alternatively, the blockchain network can implement DID registration based on smart contracts. Specifically, the blockchain network can deploy a DID management contract to register DIDs for each device or user.

[0151] Alternatively, the blockchain network can trigger a message outside the blockchain network through a smart contract, which can include the authorizer's DID. The authorizer's device can receive this message and obtain the authorizer's DID.

[0152] In an optional embodiment, to improve the security of the authorizer's DID, a trusted execution environment (TEE) can be deployed in the authorizer's device, so that the authorizer's DID can be stored in the TEE. Furthermore, to improve the security of the authorizer's private key, the authorizer's private key can also be stored in the TEE.

[0153] Optionally, the authorizer device has a trusted execution environment TEE; the blockchain network pre-registers a distributed digital identity DID for the authorizer, which may include: the blockchain network pre-receives a DID registration request sent by the authorizer device, the request including the authorizer public key created by the authorizer device in the TEE; the blockchain network pre-creates an authorizer DID identifier uniquely corresponding to the authorizer device based on the authorizer public key included in the request, stores the correspondence between the created authorizer DID identifier and the authorizer public key, and returns the created authorizer DID identifier to the TEE of the authorizer device.

[0154] Correspondingly, since the private key of the authorizer is stored in the TEE, the step of digitally signing the signature object in S101 can be executed in the TEE of the authorizer's device.

[0155] Optionally, digitally signing the signature object using the authorized party's private key corresponding to the authorized party's public key may include: acquiring target data into the TEE; and digitally signing the signature object in the TEE using the authorized party's private key stored in the TEE.

[0156] Among them, when the signature object includes the authorized party's DID identifier, the acquired target data and the authorized party's DID identifier stored in the TEE can also be directly determined as the signature object or part of the signature object in the TEE, and then the signature object can be digitally signed using the authorized party's private key stored in the TEE.

[0157] Correspondingly, since the authorizer DID is stored in the TEE, the step of generating the first verifiable statement including the authorizer DID in S102 can be executed in the TEE of the authorizer device.

[0158] Optionally, a first verifiable statement including the authorizer's DID, digital signature, and signature object may be generated in the TEE of the authorizer's device as a usage authorization certificate issued by the authorizer.

[0159] 2. Verification steps using authorization credentials.

[0160] In an optional embodiment, the generated first verifiable statement in S102 is used as a target data use authorization certificate issued by the authorizer. The first verifiable statement should be verifiable by any party to confirm that the first verifiable statement is indeed generated by the authorizer's device, thereby confirming that the authorizer has indeed granted the target data use permission to the device with the first verifiable statement.

[0161] Optionally, the first verifiable statement includes the DID identifier of the authorizer, the digital signature in S101, and the signature object. Therefore, the corresponding public key of the authorizer can be obtained from the blockchain network according to the DID identifier of the authorizer, and the digital signature in the first verifiable statement can be verified.

[0162] Specifically, the digital signature can be decrypted using the authorized party's public key to obtain the summary information to be verified, and then the standard summary information of the signature object can be obtained. If the summary information to be verified is consistent with the standard summary information, it can be determined that the digital signature verification has passed. If the summary information to be verified is inconsistent with the standard summary information, it can be determined that the digital signature verification has failed.

[0163] When the digital signature in the first verifiable statement is verified successfully, it can be determined that the first verifiable statement is generated by the authorized device, thereby proving the authorized use of the target data by the authorized device.

[0164] In the event that the digital signature in the first verifiable statement fails to be verified, it can be determined that the first verifiable statement was not generated by the authorized party device.

[0165] It should be noted that the above verification step of using the authorization certificate can be performed by the blockchain network.

[0166] Alternatively, the verifier may send the first verifiable claim to the blockchain network, which then verifies the first verifiable claim through a smart contract to verify whether the first verifiable claim was generated by the authorized device. The network then triggers an off-chain messaging mechanism to return the verification result to the verifier. The verifier is responsible for verifying the first verifiable claim and may specifically be the user or regulator.

[0167] The blockchain network verifies the first verifiable statement through a smart contract. Specifically, this may include obtaining the corresponding authorizer public key from the blockchain network based on the authorizer's DID and verifying the digital signature in the first verifiable statement. Specifically, this may include decrypting the digital signature using the authorizer public key to obtain the summary information to be verified, and then obtaining the standard summary information for the signature object. If the summary information to be verified is consistent with the standard summary information, the digital signature verification can be determined to have passed. If the summary information to be verified is inconsistent with the standard summary information, the digital signature verification can be determined to have failed.

[0168] This embodiment of blockchain network verification through smart contracts can improve the security and credibility of the verification process.

[0169] In this embodiment, the first verifiable statement can be verified to determine whether the first verifiable statement is generated by the authorization party device, thereby facilitating subsequent supervision of the use of the demand party device and determining whether the demand party device uses the target data with authorization to use the target data.

[0170] 3. The following is an explanation of S103.

[0171] S103: Send the first verifiable statement to the user demand side device through a direct connection with the user demand side device, so that the user demand side device obtains authorization to use the target data.

[0172] Optionally, a direct connection can be established directly between the authorizing party's device and the user's device without the involvement of a third party. Specifically, it can be a direct connection between devices at close range, including near-field communication, Bluetooth, and direct data cable connections. Direct connections do not include connections involving intermediaries such as wired or wireless networks.

[0173] Since a direct connection is a connection without the involvement of a third party, there is no need to rely on the network for data transmission. Specifically, the first verifiable statement generated in S102 can be transmitted. It can also improve the security of data transmission and reduce the possibility of leakage of the first verifiable statement generated in S102 during data transmission. Therefore, it will not be affected by network factors, making it convenient to conduct business.

[0174] It is understandable that since a direct connection does not involve a third party, it does not include any network connection. Network connections, such as wired network connections and wireless network connections, usually involve multiple forwarding devices for forwarding, which obviously does not meet the definition of a direct connection. Therefore, the influence of network factors can be avoided through direct connection.

[0175] In an optional embodiment, when the first verifiable statement is generated in the TEE of the authorizer device, the generated first verifiable statement can be directly sent from the TEE of the authorizer device to the user demander device through a direct connection.

[0176] Specifically, the first verifiable declaration generated can be sent from the TEE of the authorizing party's device to the NFC function module, and then the NFC function module of the authorizing party's device uses the NFC channel to send the generated first verifiable declaration to the NFC function module of the user's device, so that the user can obtain authorization to use the target data.

[0177] In an optional embodiment, after obtaining the first verifiable declaration, the user requester can directly use the target data in the first verifiable declaration to conduct business. The first verifiable declaration can also be stored as an authorization certificate for the authorizer to authorize the use of the target data, facilitating subsequent verification.

[0178] Optionally, any verification party may verify whether the use of the target data by the user requester is authorized by the authorization party. This embodiment does not limit the specific verification party, and the verification party may be the user requester itself or a supervisor.

[0179] Optionally, the demander device itself can verify the first verifiable statement to reduce the possibility of erroneous authorization or false authorization. Specifically, the demander device can verify whether the first verifiable statement is generated by the authorizer device using the above method.

[0180] Optionally, another party may verify the first verifiable statement stored in the requester's device to verify whether the requester's use of the target data is authorized by the authorizing party. Specifically, the other party may be a regulator that oversees data usage. Specifically, verification may be performed using the aforementioned method for verifying whether the first verifiable statement was generated by the authorizing party's device.

[0181] It should be noted that the aforementioned method for verifying whether the first verifiable claim was generated by the authorizer's device requires obtaining the authorizer's public key from the blockchain network. Therefore, this verification method can be performed while connected to the internet. Furthermore, verification by other parties using the first verifiable claim stored on the demander's device can also be performed while connected to the internet. Therefore, verification of the first verifiable claim can be performed while connected to the internet.

[0182] In the above method flow, the authorizer device can generate a first verifiable statement as an authorization certificate for the use of the target data based on the target data and the authorizer DID identifier, wherein the first verifiable statement can be verified based on the authorizer DID identifier and the blockchain network to verify whether the first verifiable statement is generated by the authorizer device, thereby verifying whether the use of the target data is authorized by the authorizer.

[0183] By directly connecting to the device of the user, the first verifiable statement is transmitted to the device of the user to complete the data usage authorization. The data usage authorization process is realized without the participation of a third party in the transmission, and will not be affected by network factors.

[0184] In addition, the above method flow describes that an authorizing device grants the right to use the target data to a user device. It can be understood that in situations where multiple authorizing devices grant the right to use the target data to one user device, one authorizing device grants the right to use the target data to multiple user devices, and multiple authorizing devices grant the right to use the target data to multiple user devices, the above method flow can be used to authorize data usage for any group of authorizing devices and user devices.

[0185] In addition to the above method flow, in an optional embodiment, for the first verifiable statement, in addition to verifying whether the first verifiable statement is generated by the authorizing party device, the verifier may also verify other aspects.

[0186] The following is an exemplary explanation from two aspects.

[0187] 1) The first verifiable statement may become invalid as a credential for authorization.

[0188] Specifically, it can be that the authorized party actively withdraws the right to use the target data, or the authorization certificate itself has a validity period. After the validity period expires, the device of the demander no longer has the right to use the target data, and the first verifiable declaration will also become invalid.

[0189] In the event that the first verifiable claim becomes invalid, the target data should no longer be used or stored by the demand-side device.

[0190] For the first verifiable statement, with the help of the authorized party's public key in the blockchain network, it is still possible to verify whether the first verifiable statement is generated by the authorized party's device, but it is also necessary to verify whether the first verifiable statement is invalid.

[0191] The specific method for verifying whether the first verifiable claim is invalid is not limited in this embodiment. Specific exemplary embodiments can be found below.

[0192] 2) The first verifiable statement is used as an authorization credential, and there is a possibility that the first verifiable statement may be abused.

[0193] As an example of a misuse of the first verifiable claim, after the demander's device obtains the first verifiable claim, any other device may obtain the first verifiable claim from the demander's device and use the target data based on the first verifiable claim. However, in reality, the other device does not have authorization from the authorizer.

[0194] In the conventional method of verifying whether the first verifiable statement is generated by the authorized party device, the other device does not modify the first verifiable statement. Therefore, when the other device presents the first verifiable statement, it can also be determined that the first verifiable statement is generated by the authorized party device, thereby mistakenly believing that the other device has the authorized party's authorization to use.

[0195] Therefore, other authorization content and information can be included in the first verifiable statement to help determine the device that actually has authorization to use the target data. Other content, such as the authorized device identifier and the authorized requester identifier, can be used to help determine the device that actually has authorization to use the target data.

[0196] As another example of abusing the first verifiable claim, when the authorizer only authorizes the use of the target data locally on the demander's device, the demander's device is used to send the target data to other devices, even though the demander's device does not actually have permission to send the target data.

[0197] However, in conventional methods for verifying whether the first verifiable statement is generated by the authorized party device, this point cannot be verified.

[0198] Therefore, the authorized party's designated usage permissions can be introduced in the first verifiable statement, so that the authorized party's designated usage permissions can be used to help determine whether the demander's device has performed operations other than the authorized party's designated usage permissions. Specifically, the operation records of the demander's device can be obtained for verification.

[0199] It should be noted that these other contents can be included in the signature object, and the correctness and integrity can be verified through the digital signature, thereby facilitating improving the accuracy of verifying whether the first verifiable statement has been abused.

[0200] It can be seen that, in the first verifiable statement, some other content besides the target data contained in the signature object can be used to help verify whether the first verifiable statement is abused.

[0201] Of course, this embodiment does not limit the specific circumstances in which the first verifiable statement is abused, nor does it limit other specific contents contained in the signature object and the corresponding specific verification method. Specific exemplary embodiments can be found below.

[0202] The following is a detailed explanation of the situation of verifying whether the first verifiable claim is invalid.

[0203] In an optional embodiment, the first verifiable statement, serving as a credential for authorization, may become invalid, meaning that the authorizer no longer grants the requester's device permission to use the target data. In other words, the invalidation of the first verifiable statement indicates that the requester's device no longer has permission to use the target data.

[0204] Two specific examples of methods for verifying whether the first verifiable claim is invalid are given below.

[0205] 1) In an optional embodiment, validity period information can be set in the first verifiable claim. Specifically, the validity period information can be included in the signature object to facilitate verification of the correctness and completeness of the validity period information. The validity of the first verifiable claim can then be determined by verifying the validity period information.

[0206] Optionally, when the verifier verifies whether the first verifiable statement is valid, the verifier may further obtain validity period information in the first verifiable statement for verification if the digital signature in the first verifiable statement is verified to be successful.

[0207] The verification process includes: if the current time point exceeds the obtained validity period, it can be determined that the first verifiable declaration is invalid, and the user of the requester's device no longer has permission to use the target data. If the current time point does not exceed the obtained validity period, it can be determined that the first verifiable declaration is valid, and the user of the requester's device still has permission to use the target data.

[0208] Optionally, the verifier can verify the validity of the first verifiable claim by submitting it to the blockchain network for verification. The blockchain network can receive the first verifiable claim from the verifier and, if the digital signature in the first verifiable claim is verified by the smart contract, further obtain the validity period information in the first verifiable claim for verification. The specific verification process is the same as described above. The verification result can then be returned to the verifier by triggering an off-chain message mechanism.

[0209] In this embodiment, whether the first verifiable claim is valid can be quickly and accurately verified using the validity period information in the first verifiable claim, thereby improving verification efficiency.

[0210] 2) In another optional embodiment, a revocation statement set may be deployed in the blockchain network, and the revocation statement set is used to store revocation verifiable statements, thereby facilitating the use of the revocation statement set to help verify whether the first verifiable statement is revocation.

[0211] Optionally, when the verification policy verifies whether the first verifiable claim to be verified is valid, a set of invalid claims can be determined from the blockchain network to determine whether the first verifiable claim to be verified is in the set of invalid claims.

[0212] If the first verifiable claim to be verified is in the invalid claim set, it can be determined that the first verifiable claim is invalid, and the user of the demand-side device no longer has permission to use the target data. If the first verifiable claim to be verified is not in the invalid claim set, it can be determined that the first verifiable claim is valid, and the user of the demand-side device still has permission to use the target data.

[0213] Of course, optionally, the verifier may directly send the first verifiable statement to be verified to the blockchain network for verification, or may obtain a set of invalid statements from the blockchain network and send it to the verifier for subsequent verification.

[0214] To maintain the invalidation claim set, the blockchain network can optionally monitor invalidation events in real time. Specifically, an invalidation event can be an event that indicates the invalidation of a specific verifiable claim. The verifiable claim specified by the invalidation event is then added to the invalidation claim set.

[0215] Optionally, the expiration event may include an event in which the validity period of any verifiable statement expires, and / or an event in which the authorized party proactively revokes any verifiable statement.

[0216] Specifically, the blockchain network may deploy a smart contract for maintaining the invalidation statement set, which may specifically be an authorization management smart contract. Maintaining the invalidation statement set may specifically include updating the invalidation statement set.

[0217] Optionally, the authorization management smart contract can be used to monitor failure events and add verifiable claims specified by the monitored failure events to the failure claim set.

[0218] This embodiment does not specifically limit expiration events. As an example, expiration events may include: the blockchain network receiving a revocation request from an authorizer device, where the revocation request is used to request the revocation of a specified verifiable claim; and / or, if any verifiable claim includes an expiration date, detecting that the current time point has exceeded the expiration date included in the verifiable claim.

[0219] Optionally, the authorizer can revoke the first verifiable statement sent by itself at any time. Specifically, it can send a revocation request to the blockchain network, and the revocation request can specify the first verifiable statement to revoke authorization.

[0220] Of course, to ensure that the request was initiated by the authorizer itself, the revocation request can also be signed using the authorizer's private key. The signature object can specifically be other content in the request, such as the first verifiable claim specified for revocation. The blockchain network can then verify the digital signature in the revocation request using the authorizer's public key. Once the digital signature is verified, it can be proved that the request was initiated by the authorizer, and the first verifiable claim specified in the revocation request is added to the set of invalid claims.

[0221] Optionally, the blockchain network specifically monitors the validity period of the verifiable statement, and may monitor all verifiable statements received in the past, or may collect a number of verifiable statements for monitoring. This embodiment is not limited thereto.

[0222] Specifically monitoring the validity period of the verifiable declaration may include: after monitoring that the current time point exceeds the validity period of any verifiable declaration, adding the verifiable declaration to the invalid declaration set.

[0223] In this embodiment, the invalidation statement set is maintained in the blockchain network, which can reduce the possibility of the invalidation statement set being tampered with.

[0224] This embodiment can quickly verify whether the first verifiable statement is invalid through the invalid statement set, and can provide the authorized party with the operating authority to revoke authorization and revoke the first verifiable statement at any time, thereby improving the authorized party's operating experience and the security of the target data.

[0225] It should be noted that the above two method examples can be used in combination to verify whether the first verifiable claim is invalid from multiple aspects.

[0226] The following is a detailed explanation of the situation in which the first verifiable claim is verified to be abused.

[0227] In an optional embodiment, the first verifiable statement is used as an authorization credential. There is a possibility that the first verifiable statement may be abused, causing an unauthorized object to use the target data or perform unauthorized operations on the target data.

[0228] Two specific examples of methods for verifying whether the first verifiable claim has been abused are given below.

[0229] 1) In an optional embodiment, the first verifiable statement may include an authorized object identifier.

[0230] Specifically, the signature object of the first verifiable statement may include an authorized device identification, which may uniquely correspond to the authorized device, indicating that the authorizer only grants the use right of the target data to the device corresponding to the device identification.

[0231] For ease of description, the device to be verified is referred to as a verification device, and the verification party verifies whether the first verifiable claim in the verification device is abused. Specifically, the verification can be performed to determine whether the verification device matches the device identifier in the first verifiable claim.

[0232] Optionally, the verifier can obtain the device identifier of the device to be verified and the authorization certificate for use of the target data presented by the device to be verified (i.e., the first verifiable statement). If the digital signature in the first verifiable statement passes verification, it proves that the first verifiable statement was indeed generated by the authorized device and that the signature object in the first verifiable statement is correct and complete. The device identifier to be verified can then be compared to determine whether it is the same as the device identifier in the first verifiable statement.

[0233] If the device identifier to be verified is the same as the device identifier in the first verifiable declaration, the device to be verified is a device authorized by the authorized party, and the first verifiable declaration has not been misused by an unauthorized device. If the device identifier to be verified is different from the device identifier in the first verifiable declaration, the device to be verified is not a device authorized by the authorized party, and the first verifiable declaration has been misused by an unauthorized device.

[0234] Optionally, the above device identifier can be replaced with a user identifier, which can uniquely correspond to the authorized user identifier, indicating that the authorizer only grants the use right of the target data to the user identifier corresponding to the user identifier.

[0235] Alternatively, the signature object of the first verifiable declaration can include multiple authorized device identifiers, indicating that the authorizer only grants access to the target data to multiple devices corresponding to the multiple device identifiers. This facilitates the reuse of the same first verifiable declaration to grant access to the target data to multiple devices, improving authorization efficiency.

[0236] Correspondingly, the subsequent verification process may be to determine whether the device identifications in the signature object include an identification that is identical to the identification of the device to be verified.

[0237] In this embodiment, the authorized object identifier in the first verifiable statement can be used to identify the correctly authorized object (requester or device), and the correctness and integrity of the object identifier can be verified using the digital signature. This allows verification that other unauthorized objects are using the target data based on the first verifiable statement.

[0238] 2) In an optional embodiment, the first verifiable statement may include usage rights specified by the authorizing party.

[0239] Specifically, the signature object of the first verifiable statement may include the usage rights specified by the authorizer. The usage rights specified by the authorizer may be all or part of the usage rights for the target data.

[0240] It should be noted that there are many situations for the use of target data, such as sending to other devices, modifying locally, verifying locally, etc. Therefore, all usage permissions may include: sending permission (the permission to send target data to other devices), modification permission (the permission to modify target data), verification permission (the permission to verify target data), etc.

[0241] When the authorizer grants the use rights of the target data to the device of the demander, the authorizer may specify the specific use rights of the target data that the device of the demander has. For example, the authorizer may specify that the device of the demander only has the verification permission but not other use rights. In this case, the device of the demander cannot send out the target data or modify the target data. Otherwise, operations outside the specified use rights are performed on the target data, thereby abusing the specified use rights granted to the device of the demander by the first verifiable declaration.

[0242] For ease of description, the device to be verified is referred to as a verification device, and the verification party verifies whether the first verifiable declaration in the verification device has been abused. Specifically, the verification can be performed to verify whether the verification device performs operations beyond the specified usage permissions in the first verifiable declaration.

[0243] Optionally, the verifier can obtain the operation record of the device to be verified on the target data, as well as the authorization certificate for the use of the target data presented by the device to be verified (i.e., the first verifiable statement). If the digital signature in the first verifiable statement passes verification, it proves that the first verifiable statement was indeed generated by the authorizing device and that the signature object in the first verifiable statement is correct and complete. In turn, the specified usage rights in the first verifiable statement can be determined, and it can be judged whether the operation record contains any operations outside the specified usage rights.

[0244] If the operation record contains operations outside the specified usage permissions, it can be determined that the device to be verified has abused the first verifiable statement to operate on the target data. If the operation record does not contain operations outside the specified usage permissions, it can be determined that the device to be verified has not abused the first verifiable statement.

[0245] In this embodiment, the usage rights specified by the authorizer in the first verifiable statement can be used to clearly identify the correctly authorized usage rights, and the correctness and integrity of the specified usage rights can be verified using the digital signature. This allows verification of whether the user requesting the data abuses the first verifiable statement by performing operations outside the specified usage rights on the target data.

[0246] It should be noted that the above two method examples can be used in combination to verify whether the first verifiable claim has been abused from multiple aspects. For example, verifying whether the device to be verified is an authorized device and whether the device to be verified has performed any operations outside of the specified usage permissions.

[0247] In an optional embodiment, when it is necessary to verify whether the first verifiable statement is valid, only when the first verifiable statement is valid and it is determined that the first verifiable statement is generated by the authorized party device, can it be proved that the demander device currently has the right to use the target data.

[0248] In the case where it is necessary to verify whether the first verifiable statement has been abused, only when it is determined that the first verifiable statement has not been abused and that the first verifiable statement is generated by the authorized party device, can it be proved that the demander device has the authority to use the target data.

[0249] In the case where it is necessary to verify whether the first verifiable statement is valid and whether the first verifiable statement has been abused, only when the first verifiable statement is valid, it is determined that the first verifiable statement has not been abused, and it is determined that the first verifiable statement is generated by the authorized party device, can it be proved that the demander device currently has the right to use the target data.

[0250] This embodiment does not limit the order of the three verification processes of verifying whether the first verifiable statement is generated by the authorized device, verifying whether the first verifiable statement is valid, and verifying whether the first verifiable statement is abused. The three verification processes can be executed in parallel or in sequence.

[0251] Optionally, during the execution process, if one of the verification processes fails, for example, it is determined that the first verifiable statement is invalid, or it is determined that the first verifiable statement is abused, or it is determined that the digital signature in the first verifiable statement is verified, and the first verifiable statement is not generated by the authorized party device, then the subsequent verification process does not need to be executed, and it can be directly determined that the demander device currently does not have the right to use the target data, thereby improving verification efficiency.

[0252] The present specification also provides a multi-faceted method embodiment. Figure 2 , which is a flow chart of another data usage authorization method provided in an embodiment of this specification.

[0253] Among them, the blockchain network can pre-register a distributed digital identity DID for the authorized party so that the blockchain network stores the correspondence between the authorized party's DID identifier and the authorized party's public key.

[0254] The method may include the following steps.

[0255] S201: In response to the authorization instruction of the authorizer for use of target data, the authorizer device digitally signs a signature object using the authorizer private key corresponding to the authorizer public key; the signature object includes the target data.

[0256] S202: The authorizing party device generates a first verifiable statement including the authorizing party DID, digital signature and signature object as a usage authorization certificate issued by the authorizing party.

[0257] Among them, the step of verifying whether the first verifiable statement is generated by the authorized party device includes: determining the authorized party public key corresponding to the authorized party DID identifier in the first verifiable statement through the blockchain network, using the authorized party public key to verify the digital signature in the first verifiable statement, and if the verification of the digital signature passes, determining that the first verifiable statement is generated by the authorized party device.

[0258] S203: The authorizing party device sends the first verifiable statement to the user requesting party device through a direct connection between the authorizing party device and the user requesting party device.

[0259] S204: Using the demander's device to obtain a first verifiable statement to obtain authorization to use the target data.

[0260] Optionally, the authorizer device has a trusted execution environment TEE; the blockchain network pre-registers a distributed digital identity DID for the authorizer, including: the blockchain network pre-receives a DID registration request sent by the authorizer device, the request including the authorizer public key created by the authorizer device in the TEE; the blockchain network pre-creates an authorizer DID identifier uniquely corresponding to the authorizer device based on the authorizer public key included in the request, stores the correspondence between the created authorizer DID identifier and the authorizer public key, and returns the created authorizer DID identifier to the TEE of the authorizer device.

[0261] Optionally, the signature object is digitally signed using the authorized party's private key corresponding to the authorized party's public key, including: obtaining target data into the TEE; and digitally signing the signature object in the TEE using the authorized party's private key stored in the TEE.

[0262] Optionally, the authorizing party device uses the authorizing party's private key corresponding to the authorizing party's public key to digitally sign the signature object, including: performing identity authentication on the authorizing party; when it is determined that the authorizing party has passed the identity authentication, using the authorizing party's private key corresponding to the authorizing party's public key to digitally sign the signature object.

[0263] Optionally, the authorizing party device has a trusted execution environment TEE, which stores preset identity information; identity authentication is performed on the authorizing party, including: obtaining the identity information to be authenticated of the authorizing party into the TEE; judging in the TEE whether the identity information to be authenticated successfully matches the preset identity information; and when it is determined that the identity information to be authenticated successfully matches the preset identity information, determining that the authorizing party has passed the identity authentication.

[0264] Optionally, the signature object also includes at least one of the following: the authorizing party DID identifier, the user requesting party identifier, the user requesting party device identifier, the validity period, and the authorization time information.

[0265] Optionally, the blockchain network is deployed with an authorization management smart contract; the authorization management smart contract is used to maintain a set of invalidation statements; the authorization management smart contract is used to monitor invalidation events and add the first verifiable statement specified by the monitored invalidation event to the set of invalidation statements.

[0266] Optionally, the expiration event includes: the blockchain network receives a revocation request sent by the authorizing party device, the revocation request is used to request the revocation of a specified verifiable statement; and / or when any verifiable statement includes a validity period, it is monitored that the current time point exceeds the validity period included in the verifiable statement.

[0267] Optionally, the user demander device may store a first verifiable statement to prove that the user demander's use of the target data is authorized by the authorizing party. Therefore, the verifying party is required to verify the first verifiable statement in the user demander device.

[0268] Optionally, the verifier may obtain and use the first verifiable statement from the demander's device for verification. For specific verification methods, see the above method embodiments. For example, verifying whether the first verifiable statement was generated by the authorizer's device, verifying whether the first verifiable statement is valid, and verifying whether the first verifiable statement has been abused.

[0269] For ease of understanding, this specification also provides an application example.

[0270] like Figure 3 , which is a schematic diagram of the principle of a data usage authorization method provided in an embodiment of this specification.

[0271] This includes the blockchain network, the authenticator device, the authorizer device, and the user requester device. The authorizer device can be a user's portable electronic device, while the user requester device can be an IoT device. Of course, the user requester device can also be another user's electronic device, which can use the target data on the authorizer device after authorization. The blockchain network can specifically be a distributed digital identity chain.

[0272] The authorizer device also includes a trusted execution environment (TEE) and an NFC communication module. Furthermore, a data authorization application may be installed in the authorizer device.

[0273] In addition, in this embodiment, the specific target data may be an electronic ticket. When issuing an electronic ticket, the trusted authority may use the private key corresponding to its own distributed digital identity to sign the electronic ticket to ensure the authenticity of the electronic ticket.

[0274] For ease of understanding, Figure 3 The data use authorization method is divided into three stages, namely the preparation stage, the data use authorization stage and the network supervision stage.

[0275] The preparation stage may include the following steps.

[0276] S301: Use the demander's device to obtain and store the public key corresponding to the distributed digital identity of a trusted authority in a specified blockchain via the network. For ease of description, the distributed digital identity (DID) will be referred to as the DID, and the public and private keys corresponding to the trusted authority's distributed digital identity will be referred to as the authority's public key and authority's private key, respectively.

[0277] S302: The data authorization application of the authorizer device sends a request to create a key pair to the trusted execution environment based on the user operation.

[0278] S303: The authorized device creates a pair of public and private keys in the trusted execution environment, stores the created private key, and sends the created public key to the blockchain network through the network.

[0279] S304: The blockchain network uses the received public key to create the authorized party DID identifier and bind the corresponding relationship between the authorized party DID identifier and the received public key.

[0280] S305: The blockchain network returns the authorizer’s DID to the trusted execution environment of the authorizer’s device.

[0281] The data use authorization stage may include the following steps. It should be noted that during the data use authorization stage, both the authorizing device and the user requesting device can be in an offline scenario, without the need for network participation.

[0282] S401: The data authorization application of the authorizer device obtains the target data into the trusted execution environment based on the user operation and requests to generate a digital signature.

[0283] S402: The authorizing device verifies in the trusted execution environment whether the fingerprint input by the user matches the reserved user fingerprint information. If the match is successful, S403 is executed.

[0284] S403: The authorized device uses the stored created private key in the trusted execution environment to digitally sign the target data and generate a first verifiable statement.

[0285] The first verifiable statement may include the generated digital signature, the stored authorized party DID identifier, and the target data.

[0286] S404: The authorizing device sends the first verifiable declaration to the NFC communication module in the trusted execution environment.

[0287] S405: The authorizing party device sends the first verifiable declaration to the user requesting party device through the NFC communication module.

[0288] S406: Use the demander's device to verify the signature of the target data in the first verifiable statement using the pre-stored public key of the trusted authority. If the signature verification is successful, execute S407.

[0289] S407: Use the demander's device to conduct business using the target data, and store the first verifiable statement as a usage authorization credential.

[0290] During the online supervision stage, the following steps may be included.

[0291] S501: Use a demander device to send a first verifiable claim to a verifier device.

[0292] S502: The verifier device sends the first verifiable statement to the blockchain network for verification.

[0293] S503: The blockchain network verifies the first verifiable statement and returns the verification result to the verifier device.

[0294] For the specific blockchain network verification process, please refer to the above method embodiment.

[0295] In addition, if Figure 4 The figure shows a schematic diagram of the principle of a network monitoring stage provided by an embodiment of this specification.

[0296] Among them, the authorization party device can issue a request to revoke the first verifiable statement, making the first verifiable statement invalid, so that the demander device can no longer use the first verifiable statement as an authorization credential, and thus cannot use the target data in the first verifiable statement.

[0297] Specifically, the following steps may be included.

[0298] S601: Use a demander device to send a first verifiable claim to a verifier device.

[0299] S602: The verifier device sends the first verifiable statement to the blockchain network.

[0300] S603: The authorizing device sends an invalidation request to the blockchain network, so that the first verifiable claim cannot be verified in the blockchain network. Specifically, the request may be to add the first verifiable claim to a set of invalidated claims.

[0301] S603: The blockchain network verifies the first verifiable statement, determines that the first verifiable statement fails verification, and returns a verification result indicating that the verification failed to the verifier device.

[0302] In addition, corresponding to the above method flow, the embodiments of this specification also provide system embodiments and device embodiments.

[0303] System embodiment.

[0304] like Figure 5 , which is a structural diagram of a data use authorization system provided in an embodiment of this specification, including an authorization party device 701 and a use request party device 702.

[0305] The blockchain network pre-registers the distributed digital identity DID for the authorized party so that the blockchain network stores the correspondence between the authorized party's DID identifier and the authorized party's public key.

[0306] The system includes an authorizer device 701 and a user demander device 702 .

[0307] The authorizer device 701 can be used to: respond to the authorizer's authorization instruction for the use of target data, digitally sign the signature object using the authorizer's private key corresponding to the authorizer's public key; the signature object includes the target data; generate a first verifiable statement including the authorizer's DID identifier, digital signature and signature object as a use authorization certificate issued by the authorizer; wherein, the step of verifying whether the first verifiable statement is generated by the authorizer device includes: determining the authorizer's public key corresponding to the authorizer's DID identifier in the first verifiable statement through the blockchain network, using the authorizer's public key to verify the digital signature in the first verifiable statement, and when the digital signature is verified, determining that the first verifiable statement is generated by the authorizer device; and sending the first verifiable statement to the user demand side device 702 through a direct connection with the user demand side device.

[0308] The use of the demander device 702 may be used to obtain a first verifiable statement to obtain authorization to use the target data.

[0309] Optionally, the authorizer device has a trusted execution environment TEE; the blockchain network pre-registers a distributed digital identity DID for the authorizer, including: the blockchain network pre-receives a DID registration request sent by the authorizer device, the request including the authorizer public key created by the authorizer device in the TEE; the blockchain network pre-creates an authorizer DID identifier uniquely corresponding to the authorizer device based on the authorizer public key included in the request, stores the correspondence between the created authorizer DID identifier and the authorizer public key, and returns the created authorizer DID identifier to the TEE of the authorizer device.

[0310] Optionally, the authorization party device 701 is specifically used to: obtain target data into TEE; and digitally sign the signature object in TEE using the authorization party private key stored in TEE.

[0311] Optionally, the authorizing party device 701 is specifically used to: perform identity authentication on the authorizing party; and when it is determined that the authorizing party passes the identity authentication, digitally sign the signature object using the authorizing party's private key corresponding to the authorizing party's public key.

[0312] Optionally, the authorizer device 701 has a trusted execution environment TEE, and the TEE stores preset identity information; the authorizer device 701 is specifically used to: obtain the identity information to be authenticated of the authorizer into the TEE; determine in the TEE whether the identity information to be authenticated successfully matches the preset identity information; if it is determined that the identity information to be authenticated successfully matches the preset identity information, determine that the authorizer has passed the identity authentication.

[0313] Optionally, the signature object also includes at least one of the following: the authorizing party DID identifier, the user requesting party identifier, the user requesting party device identifier, the validity period, and the authorization time information.

[0314] Optionally, the blockchain network is deployed with an authorization management smart contract; the authorization management smart contract is used to maintain a set of invalidation statements; the authorization management smart contract is used to monitor invalidation events and add the first verifiable statement specified by the monitored invalidation event to the set of invalidation statements.

[0315] Optionally, the expiration event includes: the blockchain network receives a revocation request sent by the authorizing party device, the revocation request is used to request the revocation of a specified verifiable statement; and / or when any verifiable statement includes a validity period, it is monitored that the current time point exceeds the validity period included in the verifiable statement.

[0316] Optionally, the user demander device 702 may store a first verifiable statement to prove that the user demander's use of the target data is authorized by the authorizing party.

[0317] Optionally, the verifier may obtain and use the first verifiable claim from the demander device 702 for verification. For specific verification methods, see the above method embodiments. For example, the verifier may verify whether the first verifiable claim was generated by the authorizer device 701, whether the first verifiable claim is valid, and whether the first verifiable claim has been abused.

[0318] The specific explanation of this embodiment can be found in the above method flow, which will not be repeated here.

[0319] Device embodiment.

[0320] like Figure 6 The figure shows a schematic diagram of the structure of a data use authorization device provided in an embodiment of this specification, which can be specifically applied to the authorizer device. The blockchain network pre-registers a distributed digital identity DID for the authorizer, so that the blockchain network stores the correspondence between the authorizer DID identifier and the authorizer public key;

[0321] The apparatus may include the following units.

[0322] The response unit 801 is used to respond to the authorization instruction of the authorized party to use the target data, and digitally sign the signature object using the authorized party's private key corresponding to the authorized party's public key; the signature object includes the target data.

[0323] A generating unit 802 is configured to generate a first verifiable statement including an authorizing party DID, a digital signature, and a signature object, as a use authorization certificate issued by the authorizing party; wherein the step of verifying whether the first verifiable statement is generated by the authorizing party device comprises: determining, through a blockchain network, the authorizing party public key corresponding to the authorizing party DID in the first verifiable statement, using the authorizing party public key to verify the digital signature in the first verifiable statement, and determining that the first verifiable statement is generated by the authorizing party device if the digital signature is verified successfully.

[0324] The sending unit 803 is configured to send the first verifiable statement to the user demand side device through a direct connection with the user demand side device, so that the user demand side device obtains authorization to use the target data.

[0325] Optionally, the authorizer device has a trusted execution environment (TEE); the blockchain network pre-registers a distributed digital identity (DID) for the authorizer, including: the blockchain network pre-receives a DID registration request from the authorizer device, the request including the authorizer public key created by the authorizer device in the TEE. The blockchain network pre-creates an authorizer DID uniquely corresponding to the authorizer device based on the authorizer public key included in the request, stores the correspondence between the created authorizer DID and the authorizer public key, and returns the created authorizer DID to the TEE of the authorizer device.

[0326] Optionally, the response unit 801 is specifically used to: obtain target data into the TEE; and digitally sign the signature object in the TEE using the authorized party's private key stored in the TEE.

[0327] Optionally, the response unit 801 specifically includes: an identity authentication subunit 801a, which is used to perform identity authentication on the authorized party; and a signature subunit 801b, which is used to digitally sign the signature object using the authorized party's private key corresponding to the authorized party's public key when it is determined that the authorized party has passed the identity authentication.

[0328] Optionally, the authorizing party device has a trusted execution environment TEE, which stores preset identity information; the identity authentication subunit is used to: obtain the identity information to be authenticated of the authorizing party into the TEE; determine in the TEE whether the identity information to be authenticated successfully matches the preset identity information; and when it is determined that the identity information to be authenticated successfully matches the preset identity information, determine that the authorizing party has passed the identity authentication.

[0329] Optionally, the signature object also includes at least one of the following: the authorizing party DID identifier, the user requesting party identifier, the user requesting party device identifier, the validity period, and the authorization time information.

[0330] Optionally, the blockchain network is deployed with an authorization management smart contract; the authorization management smart contract is used to maintain a set of invalidation statements; the authorization management smart contract is used to monitor invalidation events and add verifiable statements specified by the monitored invalidation events to the set of invalidation statements.

[0331] Optionally, the expiration event includes: the blockchain network receives a revocation request sent by the authorizing party device, the revocation request is used to request the revocation of a specified verifiable statement; and / or when any verifiable statement includes a validity period, it is monitored that the current time point exceeds the validity period included in the verifiable statement.

[0332] The specific explanation of the above device embodiment can be found in the above method flow, which will not be repeated here.

[0333] An embodiment of this specification also provides a computer device, which includes at least a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps executed by the authorizing device or the demanding device in a data usage authorization method are implemented.

[0334] Figure 7 10 is a schematic diagram showing a more specific hardware structure of a computer device provided in an embodiment of this specification. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are connected to each other within the device via the bus 1050.

[0335] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0336] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory 1020 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0337] The input / output interface 1030 is used to connect input / output modules to implement information input and output. The input / output modules can be configured as components within the device (not shown in the figure) or can be externally connected to the device to provide corresponding functions. Input devices may include a keyboard, mouse, touch screen, microphone, various sensors, etc., and output devices may include a display, speaker, vibrator, indicator light, etc.

[0338] The communication interface 1040 is used to connect to a communication module (not shown) to enable communication between the device and other devices. The communication module can communicate via a wired method (such as USB, network cable, etc.) or a wireless method (such as mobile network, WiFi, Bluetooth, etc.).

[0339] The bus 1050 comprises a path for transmitting information between the various components of the device (eg, the processor 1010 , the memory 1020 , the input / output interface 1030 , and the communication interface 1040 ).

[0340] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above device may only include the components necessary to implement the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0341] The embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements steps performed by an authorizing device or a demanding device in a data usage authorization method.

[0342] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules, 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 disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0343] Through the description of the above implementation methods, it can be known that those skilled in the art can clearly understand that the embodiments of this specification can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solutions of the embodiments of this specification, or the part that contributes to the prior art, can be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiments of this specification.

[0344] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0345] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The device embodiment described above is merely illustrative, wherein the modules described as separate components may or may not be physically separated, and when implementing the embodiment scheme of this specification, the functions of each module can be implemented in the same one or more software and / or hardware. It is also possible to select some or all of the modules according to actual needs to achieve the purpose of the embodiment scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0346] The above is only a specific implementation of the embodiment of this specification. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the embodiment of this specification. These improvements and modifications should also be regarded as protection for the embodiment of this specification.

Claims

1. A data usage authorization method, applied to an authorizer device; a blockchain network pre-registers a distributed digital identity (DID) for the authorizer, so that the blockchain network stores a correspondence between the authorizer's DID identifier and the authorizer's public key; the method comprising: In response to an authorization instruction from an authorized party to authorize the use of target data, digitally sign a signature object using a private key of the authorized party corresponding to a public key of the authorized party; the signature object includes the target data; Generate a first verifiable statement including the authorizer DID, the digital signature, and the signature object as a use authorization certificate issued by the authorizer; wherein the step of verifying whether the first verifiable statement is generated by the authorizer device includes: determining, through the blockchain network, the authorizer public key corresponding to the authorizer DID in the first verifiable statement, using the authorizer public key to verify the digital signature in the first verifiable statement, and if the digital signature is verified successfully, determining that the first verifiable statement was generated by the authorizer device; The first verifiable statement is sent to the user requester device through a direct connection with the user requester device, so that the user requester device obtains authorization to use the target data.

2. The method according to claim 1, wherein the authorizer device has a trusted execution environment (TEE); The blockchain network pre-registers a distributed digital identity DID for the authorized party, including: The blockchain network pre-receives a DID registration request sent by the authorizer device, wherein the request includes the authorizer public key created by the authorizer device in the TEE; The blockchain network creates an authorizer DID identifier uniquely corresponding to the authorizer device based on the authorizer public key included in the request in advance, stores the correspondence between the created authorizer DID identifier and the authorizer public key, and returns the created authorizer DID identifier to the TEE of the authorizer device.

3. The method according to claim 2, wherein the step of digitally signing the signature object using the authorized party's private key corresponding to the authorized party's public key comprises: Acquire the target data into the TEE; The signature object is digitally signed in the TEE using the authorized party's private key stored in the TEE.

4. The method according to claim 1, wherein the step of digitally signing the signature object using the authorized party's private key corresponding to the authorized party's public key comprises: Perform identity authentication for authorized parties; When it is determined that the authorized party has passed the identity authentication, the signature object is digitally signed using the authorized party's private key corresponding to the authorized party's public key.

5. The method according to claim 4, wherein the authorizing party device has a trusted execution environment (TEE), and the TEE stores preset identity information; The identity authentication for the authorized party includes: Obtain the identity information of the authorized party to be authenticated into the TEE; In the TEE, it is determined whether the identity information to be authenticated successfully matches the preset identity information; if it is determined that the identity information to be authenticated successfully matches the preset identity information, it is determined that the authorized party has passed the identity authentication.

6. According to the method according to any one of claims 1 to 5, the signature object further includes at least one of the following: the DID identifier of the authorizing party, the identifier of the user requesting party, the device identifier of the user requesting party, the validity period, and the authorization time information.

7. The method according to claim 1, wherein the blockchain network is deployed with an authorization management smart contract; the authorization management smart contract is used to maintain a set of invalidation declarations; The authorization management smart contract is used to monitor failure events and add verifiable claims specified by the monitored failure events to the failure claim set.

8. The method according to claim 7, wherein the failure event comprises: The blockchain network receives a revocation request sent by the authorizer device, wherein the revocation request is used to request revocation of a specified verifiable claim; and / or In the case where any verifiable statement includes an expiration date, it is detected that the current time point exceeds the expiration date included in the verifiable statement.

9. A data use authorization method, wherein a blockchain network pre-registers a distributed digital identity (DID) for an authorizer, so that the blockchain network stores a correspondence between the authorizer's DID identifier and the authorizer's public key; The method comprises: The authorizing party device responds to the authorizing party's instruction to authorize the use of the target data by using the authorizing party's private key corresponding to the authorizing party's public key to digitally sign the signature object; the signature object includes the target data; The authorizing party device generates a first verifiable statement including the authorizing party DID, the digital signature, and the signature object as a use authorization certificate issued by the authorizing party; wherein the step of verifying whether the first verifiable statement is generated by the authorizing party device includes: determining, through the blockchain network, the authorizing party public key corresponding to the authorizing party DID in the first verifiable statement, using the authorizing party public key to verify the digital signature in the first verifiable statement, and determining that the first verifiable statement is generated by the authorizing party device if the digital signature is verified successfully; The authorizing device sends the first verifiable statement to the user requesting device through a direct connection between the authorizing device and the user requesting device; The user obtains the first verifiable statement using the demander device to obtain authorization to use the target data.

10. A data usage authorization device for an authorizer device; a blockchain network pre-registers a distributed digital identity (DID) for the authorizer, so that the blockchain network stores the corresponding relationship between the authorizer DID identifier and the authorizer public key; The device comprises: a response unit, configured to digitally sign a signature object using a private key of the authorizer corresponding to the public key of the authorizer in response to an authorization instruction of the authorizer for use of the target data; the signature object includes the target data; a generating unit, configured to generate a first verifiable statement including the authorizing party DID, the digital signature, and the signature object, as a use authorization certificate issued by the authorizing party; wherein the step of verifying whether the first verifiable statement was generated by the authorizing party device comprises: determining, through the blockchain network, the authorizing party public key corresponding to the authorizing party DID in the first verifiable statement, using the authorizing party public key to verify the digital signature in the first verifiable statement, and determining that the first verifiable statement was generated by the authorizing party device if the digital signature is verified successfully; The sending unit is configured to send the first verifiable statement to the user demand side device through a direct connection with the user demand side device, so that the user demand side device obtains authorization to use the target data.

11. A data use authorization system, wherein a blockchain network pre-registers a distributed digital identity (DID) for an authorizer, so that the blockchain network stores a correspondence between the authorizer's DID and the authorizer's public key; The system includes an authorization party device and a user demand party device; The authorizing party device is used to: respond to the authorizing party's authorization instruction for use of target data, digitally sign the signature object using the authorizing party's private key corresponding to the authorizing party's public key; the signature object includes the target data; generate a first verifiable statement including the authorizing party's DID, the digital signature and the signature object as a use authorization certificate issued by the authorizing party; wherein, The step of verifying whether the first verifiable statement is generated by the authorizer device includes: determining, through the blockchain network, the authorizer public key corresponding to the authorizer DID identifier in the first verifiable statement, using the authorizer public key to verify the digital signature in the first verifiable statement, and determining that the first verifiable statement is generated by the authorizer device if the digital signature is verified successfully; and sending the first verifiable statement to the user demander device through a direct connection with the user demander device; The user demander device is used to obtain the first verifiable statement to obtain authorization to use the target data.

12. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 8 is implemented.

13. A machine-readable storage medium having a program stored thereon, wherein when the program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images