Resource data processing method and device

Abstract

An embodiment of the present specification provides a resource data processing method and apparatus, the method comprising: a first business platform receiving a resource search request including a search keyword from a first user; the first business platform searching for a target resource summary that matches the search keyword among several stored resource summaries associated with the first user; the first business platform sending a resource detail acquisition request including a first DID of the first business platform and a resource identifier of the first resource to the second business platform in response to the target resource summary being a resource summary of a first resource owned by the first user in the second business platform; the second business platform returning a first acquisition result including the resource identifier and a ciphertext of the resource details of the first resource to the first business platform after confirming that the first business platform has viewing authority for the first resource; the first business platform decrypting the ciphertext of the resource details to obtain a decrypted resource detail, and providing the decrypted resource detail to the first user.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of computer technology, and more particularly, to resource data processing methods and devices. Background Art

[0002] Currently, a user can use services provided by multiple business platforms and own resource data in each of these platforms, such as membership card data and / or NFT (Non-Fungible Token) resource data. This resource data itself is an important user identity resource and is generally stored in the business platform to which it belongs. Summary of the Invention

[0003] The purpose of the present invention is to provide a resource data processing solution that can provide the ability to search and access identity resources based on keywords (also called key words) based on the aggregation of identity resources of the same user in different channels (business platforms), so as to realize the search of the full amount of identity resources of the user in any channel under the premise of user authorization.

[0004] A first aspect of the present specification provides a resource data processing method, comprising: a first business platform receiving a resource search request from a first user, the resource search request including a search keyword; the first business platform searching for a target resource summary matching the search keyword from a plurality of stored resource summaries associated with the first user, the plurality of resource summaries including resource summaries of resources owned by the first user in other business platforms, the resource summaries being obtained by the first business platform from the other business platforms after authorization by the first user; in response to the target resource summary being the resource summary of a first resource owned by the first user in a second business platform, the first business platform sending a resource detail acquisition request to the second business platform, the resource detail acquisition request including a first decentralized identity (DID) of the first business platform and a resource identifier of the first resource; after confirming that the first business platform has permission to view the first resource, the second business platform acquiring a ciphertext of resource details of the first resource based on the resource detail acquisition request, and returning a first acquisition result including the resource identifier and the ciphertext of resource details to the first business platform; the first business platform decrypting the ciphertext of resource details to obtain decrypted resource details, and providing the decrypted resource details to the first user.

[0005] A second aspect of this specification provides a resource data processing method, which is applied to a first business platform, comprising: receiving a resource search request from a first user, the resource search request including a search keyword; searching for a target resource summary that matches the search keyword among several stored resource summaries associated with the first user, the several resource summaries including resource summaries of resources owned by the first user in other business platforms, the resource summaries being obtained by the first business platform from the other business platforms after authorization by the first user; in response to the target resource summary being the resource summary of a first resource owned by the first user in a second business platform, sending a resource detail acquisition request to the second business platform, the resource detail acquisition request including a first decentralized identity DID of the first business platform and a resource identifier of the first resource; receiving a first acquisition result returned by the second business platform, the first acquisition result being sent by the second business platform after confirming that the first business platform has viewing authority for the first resource, and including the resource identifier and a ciphertext of the resource details of the first resource; decrypting the ciphertext of the resource details to obtain a decrypted resource detail, and providing the decrypted resource detail to the first user.

[0006] According to a third aspect of the present specification, there is provided a resource data processing device, which is applied to a first business platform, comprising: a receiving unit, configured to receive a resource search request of the first user, wherein the resource search request includes a search keyword; a searching unit, configured to search for a target resource summary that matches the search keyword in a plurality of stored resource summaries associated with the first user, wherein the plurality of resource summaries include resource summaries of resources owned by the first user in other business platforms, and the resource summaries are obtained by the first business platform from the other business platforms after authorization by the first user; and a sending unit, configured to send a request in response to the target resource summary being a resource summary of a first resource owned by the first user in a second business platform. Resource summary, sending a resource detail acquisition request to the second business platform, the resource detail acquisition request including the first decentralized identity identifier DID of the first business platform and the resource identifier of the first resource; the receiving unit is also configured to receive a first acquisition result returned by the second business platform, the first acquisition result is sent by the second business platform after confirming that the first business platform has the viewing permission for the first resource, and includes the resource identifier and the resource detail ciphertext of the first resource; the decryption unit is configured to decrypt the resource detail ciphertext to obtain the decrypted resource details; the sending unit is also configured to provide the decrypted resource details to the first user.

[0007] A fourth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method described in any implementation manner in the second aspect.

[0008] A fifth aspect of this specification provides a computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in any implementation manner in the second aspect is implemented.

[0009] A sixth aspect of this specification provides a computer program, which, when executed in a computer, causes the computer to execute the method described in any implementation manner in the second aspect.

[0010] In the solution provided by the embodiments of this specification, for any business platform used by a first user (hereinafter referred to as the first business platform), it can obtain resource summaries of resources owned by the first user from other business platforms after the first user's authorization, and store the obtained resource summaries in association with the first user. This can achieve the aggregation of the first user's identity resources across different channels. Based on the aggregation of the first user's identity resources across different channels, the first business platform can receive a resource search request from the first user including a search keyword, search for a target resource summary that matches the search keyword among several stored resource summaries associated with the first user, and in response to the target resource summary being the resource summary of a first resource owned by the first user in the second business platform, send a resource detail acquisition request for the first resource to the second business platform. Then, after confirming that the first business platform has the viewing permission for the first resource, the second business platform can return a first acquisition result including the resource identifier of the first resource and the ciphertext of the resource details to the first business platform. The first business platform can then decrypt the ciphertext of the resource details to obtain the decrypted resource details, and provide the decrypted resource details to the first user. Therefore, this solution can provide keyword-based identity resource search and access capabilities based on the aggregation of identity resources of the same user in different channels, so that all identity resources of the user can be searched in any channel under the premise of user authorization. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0012] Figure 1 This is a diagram of a blockchain architecture in one embodiment;

[0013] Figure 2 This is a schematic diagram of an application scenario in which the embodiments of this specification can be applied;

[0014] Figure 3 This is a timing diagram of the subject registration process in the embodiment of this specification;

[0015] Figure 4 This is a timing diagram of the real-name authentication process of user User1 in the embodiment of this specification;

[0016] Figure 5 This is a timing diagram of the issuance process of resource R1 in the embodiment of this specification;

[0017] Figure 6 This is a timing diagram of the resource intercommunication authorization process for resource R1 in the embodiment of this specification;

[0018] Figure 7 is a timing diagram of the resource data processing method in the embodiment of this specification;

[0019] Figure 8 It is a structural diagram of the resource data processing device in the embodiment of this specification. DETAILED DESCRIPTION

[0020] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0021] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain, data blocks are linked sequentially in chronological order to form a chain-like data structure, and cryptography is used to ensure that these blocks cannot be tampered with or forged. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application.

[0022] Figure 1 FIG1 shows a blockchain architecture diagram in one embodiment. Figure 1 In the blockchain architecture diagram shown, the blockchain 100 includes N nodes. Figure 1Nodes 1 through 8 are schematically shown. The lines connecting the nodes schematically represent P2P (peer-to-peer) connections, such as TCP connections, for transmitting data between nodes. These nodes can store the full ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain can generate the same state by executing the same transactions, and each node in the blockchain can store the same state database.

[0023] A transaction in the blockchain field can refer to a task unit executed and recorded in the blockchain. A transaction typically includes a sender field (From), a receiver field (To), and a data field (Data). In the case of a transfer transaction, the From field indicates the address of the account initiating the transaction (i.e., initiating a transfer task to another account), the To field indicates the address of the account receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0024] Blockchains offer smart contract functionality. Smart contracts on blockchains are contracts that can be triggered and executed by transactions within the blockchain system. Smart contracts can be defined in code. Calling a smart contract on a blockchain involves initiating a transaction to the smart contract address, allowing each node in the blockchain to execute the smart contract code in a distributed manner.

[0025] In the scenario of deploying a contract, for example, Bob sends a transaction containing the information of creating a smart contract (ie deploying the contract) to Figure 1 In the blockchain shown, the transaction's data field contains the code (such as bytecode or machine code) for the contract to be created. The transaction's to field is empty, indicating that the transaction is for contract deployment. After the nodes reach consensus through the consensus mechanism, they determine the contract address "0x6f8ae93..." Each node adds a contract account corresponding to the smart contract's contract address to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash of the contract code in the contract's state storage, successfully creating the contract.

[0026] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to Figure 1 In the blockchain shown, the transaction's "from" field is the address of the transaction initiator (Bob), the "to" field is "0x6f8ae93..." (the address of the smart contract being called), and the transaction's "data" field contains the method and parameters for calling the smart contract. After consensus is reached on the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract and updating the state database based on the contract's execution.

[0027] As mentioned above, the same user can use the business services provided by multiple business platforms and own resource data in each of these multiple business platforms, such as membership card data and / or NFT resource data. These resource data are themselves important user identity resources and are generally stored in the business platform to which they belong.

[0028] Currently, due to platform fragmentation, the identity resources of the same user cannot be associated and aggregated, making it impossible for users to search for all of their identity resources on any business platform. To address this technical issue, the embodiments of this specification provide a resource data processing solution that aggregates the identity resources of the same user across different channels and provides keyword-based identity resource search and access capabilities. This enables the full range of a user's identity resources to be searched on any channel with user authorization.

[0029] See Figure 2 , which is a schematic diagram of an application scenario in which the embodiment of this specification can be applied. Figure 2 The illustrated application scenario may include a business platform 201, a business platform 202, a user device 203 used by user User1, and a blockchain 204. Business platforms 201 and 202 may be platforms that provide any service (e.g., shopping, financial management, and / or insurance). Blockchain 204 may include N nodes. For an explanation of these N nodes, please refer to the relevant description above and will not be repeated here.

[0030] User User1 can be a natural person or an organization (such as an enterprise), and can be a user of business platform 201 and business platform 202. User User1 can apply for resources from business platform 201 and / or business platform 202 through user device 203 according to actual needs. Business platform 201 and / or business platform 202 can issue resources to user User1 and store relevant resource information of the issued resources in blockchain 204.

[0031] For either business platform 201 or business platform 202, for example, business platform 202, when user User1 obtains resource R1 on business platform 202, user User1 can authorize business platform 201 to view resource R1. After user User1's authorization, business platform 201 can obtain the resource summary of resource R1 from business platform 202 and associate the resource summary with user User1 for storage. This allows aggregation of user User1's identity resources across different channels.

[0032] When user User1 wants to search for resources owned by them on service platform 201, they can provide search keywords to service platform 201 via user device 203. Service platform 201 can then search for a target resource summary that matches the search keyword from among several stored resource summaries associated with user User1. If the target resource summary found is the resource summary of resource R1 owned by user User1 on service platform 202, service platform 201 can retrieve the resource details of resource R1 from service platform 202 and provide the retrieved resource details to user User1.

[0033] Through the resource data processing process described above, we can provide keyword-based identity resource search and access capabilities based on the aggregation of identity resources of the same user in different channels, so that all identity resources of the user can be searched in any channel under the premise of user authorization.

[0034] The resource data processing solution provided by the embodiments of this specification is introduced below in conjunction with specific embodiments.

[0035] In one embodiment, only business platforms registered as entities in the blockchain are eligible for resource interoperability. Therefore, before interoperating resources, business platforms 201 and 202 must register as entities in blockchain 204. For example, business platforms 201 and 202 can each send a transaction for entity registration to a node in blockchain 204, which can include registration information. By executing this transaction, the node in blockchain 204 can store this registration information in blockchain 204. This registration information may include a tag identifying the corresponding business platform as the entity, the platform name of the business platform, and the public key of the business platform. Furthermore, this registration information may also include platform address information for several business platforms that can communicate with the business platform. In one example, this platform address information may include the IP (Internet Protocol) addresses of these several business platforms, which can be referred to as an IP whitelist.

[0036] As an implementation method, business platform 201 and business platform 202 both include digital identity basic components (also called digital identity basic bases), and business platform 201 and business platform 202 can communicate through the digital identity basic components, and blockchain 204 can communicate with the digital identity basic components of each of business platform 201 and business platform 202.

[0037] The digital identity infrastructure component can include software and hardware resources. It can be a unified component that provides the development, listing, release, deployment, and interoperability of Dapps (Decentralized Applications), and generally one component is deployed by one entity. In one example, the digital identity infrastructure component can include a digital identity scaffolding. The digital identity scaffolding can be a basic suite that provides a one-stop digital identity Dapp development, which can reduce the development cost of Dapps. The digital identity scaffolding can include capabilities such as the issuance and authentication of DIDs (Decentralized Identifiers), cross-entity service interoperability (including privacy computing), on-chain identity contract calls, and a cross-entity identity resource search engine.

[0038] In the following, the digital identity basic component included in the business platform 201 is the first digital identity basic component, and the digital identity basic component included in the business platform 202 is the second digital identity basic component. Figure 3 This section describes the principal registration process.

[0039] See Figure 3 , which is a time sequence diagram of the subject registration process. Figure 3 As shown, in step S301, the first digital identity infrastructure component sends a transaction Tx4 for subject registration to a node on blockchain 204. Transaction Tx4 includes the registration information of business platform 201. In step S303, the node on blockchain 204 executes transaction Tx4 to store the registration information of business platform 201 in blockchain 204. In step S305, the second digital identity infrastructure component sends a transaction Tx5 for subject registration to a node on blockchain 204. Transaction Tx5 includes the registration information of business platform 202. In step S307, the node on blockchain 204 executes transaction Tx5 to store the registration information of business platform 202 in blockchain 204.

[0040] For explanations of registration information, please refer to the relevant instructions in the previous article, which will not be repeated here.

[0041] In one embodiment, a smart contract C for resource interoperability processing may be deployed in blockchain 204, transactions Tx4 and Tx5 may call smart contract C, and the respective registration information of business platform 201 and business platform 202 may be specifically stored in the contract status of smart contract C.

[0042] In one embodiment, in order to achieve the aggregation of identity resources of the same user in different channels, the user needs to have a decentralized identity so that different business platforms can identify the user's identity based on the decentralized identity. In practice, a decentralized identity can be a new type of identifier that is globally unique, highly available, resolvable, and cryptographically verifiable. DIDs are typically associated with cryptographic materials (such as public keys) and service endpoints to establish a secure communication channel. DIDs are useful for any application that benefits from self-managed, cryptographically verifiable identifiers (such as personal identifiers, organizational identifiers, and IoT scenario identifiers). For example, current commercial deployments of W3C verifiable credentials make extensive use of DIDs to identify people, organizations, and things, and implement many security and privacy protection guarantees.

[0043] Based on this, users need to obtain a decentralized identity before applying for resources from the service platform. As an example, user User1 can obtain a decentralized identity from an identity issuing authority (such as a VC (Verifiable Claim) issuing authority) that is recognized by both service platform 201 and service platform 202. The identity issuing authority can be an authoritative organization.

[0044] In one embodiment, user User1 can use user device 203 to send a real-name authentication request to the server of the identity issuing authority (hereinafter referred to as the first server). After the first server successfully authenticates user User1, it can generate a decentralized identity identifier (hereinafter referred to as the second DID) for user User1 and return the second DID to user device 203.

[0045] In another embodiment, for any one of the business platforms 201 and 202, such as the business platform 202, the business platform 202 may further include an identity issuance Dapp associated with the identity issuing authority, which may be deployed, for example, in the second digital identity infrastructure component. The identity issuance Dapp may be pulled from the identity issuing authority, such as from the first server of the identity issuing authority. User 1 may use user device 203 to obtain a decentralized identity from the identity issuance Dapp. It should be noted that when the identity issuing authority is a VC issuing authority, the identity issuance Dapp associated with the identity issuing authority may be referred to as a VC issuing Dapp.

[0046] Below, we take the example of issuing Dapp as VC, combined with Figure 4 This section describes the process of user User1 obtaining a decentralized identity from a VC-issued Dapp.

[0047] See Figure 4, which is a timing diagram of the real-name authentication process of user User1.

[0048] like Figure 4 As shown, first, in step S401, the user device 203 sends a real-name authentication request of user User1 to the VC issuing Dapp.

[0049] In step S403, VC issues Dapp to perform real-name authentication on user User1 based on the real-name authentication request.

[0050] In one example, the real-name authentication request may include the biometric information of user User1 (such as facial features, palm print features, or fingerprint features, etc.), and the VC-issuing Dapp can verify the biometric information. In another example, the real-name authentication request may include the identity elements of user User1, and the VC-issuing Dapp can verify the identity elements. When user User1 is a natural person, the identity elements may include, for example, the name and identity code of user User1; when user User1 is an enterprise, the identity elements may include, for example, the name of the enterprise's business license, the unified social credit code, the name of the legal representative, and the identity code of the legal representative. In another example, the VC-issuing Dapp can perform real-name authentication on user User1 via text message.

[0051] In step S405, after VC issues Dapp to authenticate user User1, it generates a second DID for user User1.

[0052] As an example, the real-name authentication request may include the public key of user User1, and the second DID may be generated based on the public key. For example, the second DID may be a hash value obtained by hashing the public key.

[0053] In step S407 , the VC issuing Dapp returns the second DID to the user device 203 .

[0054] In one embodiment, after the VC issuing Dapp generates a second DID for user User1, it may also issue a verifiable claim (hereinafter referred to as the first VC) to user User1 containing the second DID. In step S407, the first VC may be specifically returned to user device 203. The first VC may also include, for example, at least one of the following: user User1's public key, user User1's identity factor, the decentralized identity of the VC issuing authority (hereinafter referred to as the fourth DID), issuance time, and the signature of the VC issuing authority.

[0055] In one embodiment, the VC issuing Dapp may store the second identity information of user User1 in the blockchain 204 , where the second identity information includes the second DID, the identifier of the first VC, and the fourth DID of the VC issuing authority.

[0056] Specifically, the VC issuing Dapp can send a transaction Tx6 including the second identity information to the node of blockchain 204. The node of blockchain 204 can store the second identity information in blockchain 204 by executing transaction Tx6. It should be noted that when the above-mentioned smart contract C is deployed in blockchain 204, transaction Tx6 can call the above-mentioned smart contract C, and the second identity information can be specifically stored in the contract state of the above-mentioned smart contract C.

[0057] Optionally, the second identity information may also include the public key of user User1, the signature of the VC issuing authority, and the timestamp generated when the signature is made. It should be noted that when the first VC includes the identity element of user User1, the identifier of the first VC can be obtained by hashing the identity element.

[0058] In one embodiment, when user User1 wishes to apply for resource R1 on service platform 202, user User1 may send a resource application request for resource R1 to service platform 202 via user device 203. This resource application request may include user User1's first identity information. The first identity information may include user User1's identity elements and / or second DID. After confirming that user User1 has passed identity authentication based on the first identity information and obtaining the second DID, service platform 202 may generate and store third resource information for resource R1. The third resource information may include resource identifier, resource summary, resource details, and the second DID. Furthermore, the third resource information may include resource usage traceability information, expiration date, and issuance date. The resource usage traceability information may be empty in the initial third resource information. Service platform 202 may also generate first resource information for resource R1 and store the first resource information in blockchain 204. The first resource information may include resource identifier, second DID, and a hash value of resource R1's resource summary (hereinafter referred to as the first hash value). In addition, the service platform 202 may return the resource identifier of the resource R1 to the user equipment 203 .

[0059] In practice, resource R1 can be issued in the business platform 202 by a resource issuing agency (such as a brand or merchant settled in the business platform 202), and the third resource information may also include the decentralized identity identifier of the resource issuing agency (hereinafter referred to as the third DID). The first resource information may also include the third DID and the platform DID information provided by the resource issuing agency. The platform DID information includes the DIDs of several business platforms that can view resource R1. In one example, the platform DID information can be called a visible platform DID whitelist. The resource summary may include, for example, the resource category, resource name, resource issuing agency name, and issuer name. The resource details may include, for example, a description of the resource attribute field and a resource detail key-value pair.

[0060] In one embodiment, the business platform 202 may include a resource issuance Dapp associated with a resource issuance authority. Resource R1 may be issued by the resource issuance Dapp to user User1. The resource issuance Dapp may be deployed in the second digital identity infrastructure component. It should be noted that the resource issuance Dapp may be developed and deployed on the second digital identity infrastructure component based on the resource issuance requirements of the resource issuance authority; alternatively, the resource issuance Dapp may be pulled from the resource issuance authority, for example, from the resource issuance authority's institutional server.

[0061] Next, combine Figure 5 This section describes the process of the resource issuance Dapp issuing resource R1 to user User1.

[0062] See Figure 5 , which is a timing diagram of the issuance process of resource R1.

[0063] like Figure 5 As shown, first, in step S501, the user device 203 sends a resource application request for resource R1 to the resource issuing Dapp, and the resource application request includes the first identity information of user User1.

[0064] The first identity information may include the identity element of user User1 and / or the second DID.

[0065] In step S503, the resource issuing Dapp confirms that user User1 has passed the identity authentication based on the first identity information and obtains the second DID.

[0066] Specifically, the resource issuance Dapp can authenticate the identity of user User1 through an identity authentication agency recognized by both the business platform 201 and the business platform 202. The identity authentication agency can be an authoritative agency.

[0067] In one embodiment, the resource issuance Dapp can authenticate the user User1 through the institutional server of the identity authentication institution (hereinafter referred to as the second server). For example, when the first identity information includes the identity element of user User1 and the second DID, the resource issuance Dapp can send a second indication message to the second server, and the second indication message includes the identity element and is used to instruct the user User1 to authenticate. The second server can authenticate the user User1 based on the identity element, and after the user User1 passes the identity authentication, it returns the identity authentication result to the resource issuance Dapp. In addition, the resource issuance Dapp can obtain the second DID from the first identity information.

[0068] When the first identity information includes the identity element of user User1 but does not include the second DID, and the identifier of the first VC is obtained by hashing the identity element of user User1 included in the first VC, the resource issuance Dapp can send a first indication message to the second server, the first indication message includes the identity element, and is used to instruct the user User1 to authenticate and match the DID. The second server can authenticate user User1 based on the identity element, and after user User1 passes the authentication, hash the identity element to obtain a second hash value, obtain the second DID from the blockchain 204 based on the second hash value, and return the second DID to the resource issuance Dapp. The resource issuance Dapp can confirm that user User1 has passed the authentication in response to receiving the second DID returned by the second server.

[0069] When the first identity information includes the second DID but does not include the identity elements of user User1, the resource issuance Dapp can send a third instruction message to the second server. The third instruction message includes the second DID and is used to instruct the second server to authenticate user User1. The second server can authenticate user User1 based on the second DID and return an authentication result to the resource issuance Dapp after user User1 passes the authentication. In addition, the resource issuance Dapp can obtain the second DID from the first identity information.

[0070] In another embodiment, the business platform 202 may include an identity authentication Dapp. The identity authentication Dapp may be associated with an identity authentication authority. The identity authentication Dapp may be pulled from the identity authentication authority, for example, from a second server of the identity authentication authority. The resource issuance Dapp may authenticate user User1 through the identity authentication Dapp.

[0071] Among them, the identity authentication process when the first identity information includes the identity elements of user User1 and the second DID, and the identity authentication process when the first identity information includes the second DID but does not include the identity elements of user User1, can refer to the identity authentication process based on the second server in the previous article, and will not be repeated here.

[0072] When the first identity information includes the identity elements of user User1 but does not include the second DID, the resource issuance Dapp may send a first indication message to the identity authentication Dapp. The first indication message includes the identity elements of user User1 and instructs the authentication and DID matching process to proceed. The identity authentication Dapp may then authenticate user User1 based on the identity elements. In one example, the identity authentication Dapp may store an identity element template for user User1 and compare this identity element template with the identity elements in the first indication message to determine whether user User1 has passed authentication. In another example, the identity authentication Dapp may authenticate user User1 by interacting with a second server. For example, the second server may store an identity element template for user User1. The identity authentication Dapp may provide the identity elements in the first indication message to the second server, causing the second server to compare the identity elements with the identity element template and return a comparison result. Based on this comparison result, the identity authentication Dapp may determine whether user User1 has passed authentication. After user User1 has passed authentication, the identity authentication Dapp may hash the identity elements of user User1 to obtain a second hash value. Afterwards, the identity authentication Dapp can obtain the second DID from blockchain 204 based on the second hash value. Specifically, the identity authentication Dapp can send transaction Tx7 to a node on blockchain 204. Transaction Tx7 includes the second hash value and is used to obtain the second DID. By executing transaction Tx7, the node can find the second identity information of user User1 based on the second hash value and obtain the second DID from the second identity information. The node can then return the second DID to the identity authentication Dapp. It should be noted that when the above-mentioned smart contract C is stored in blockchain 204, transaction Tx7 can call the above-mentioned smart contract C. After receiving the second DID returned by the node, the identity authentication Dapp can return the second DID to the resource issuing Dapp.

[0073] After the resource issuance Dapp confirms that user User1 has passed identity authentication and obtained the second DID by executing step S503, it can proceed to step S505. In one example, the resource application request can also include user User1's signature of the first identity information. This signature can be generated based on user User1's private key. The resource issuance Dapp can verify the signature based on user User1's public key. After confirming that user User1 has passed identity authentication and obtained the second DID, and the signature is verified, the resource issuance Dapp can proceed to step S505.

[0074] In step S505, the resource issuance Dapp generates and stores the third resource information of resource R1, where the third resource information includes the resource identifier of resource R1, the resource summary of resource R1, the resource details of resource R1, the second DID, and the third DID.

[0075] In step S507, the resource issuing Dapp generates first resource information, which includes the resource identifier of resource R1, the second DID, the first hash value of the resource summary of resource R1, the third DID, and the platform DID information provided by the resource issuing authority. The platform DID information includes the DIDs of several business platforms that can view resource R1.

[0076] In step S509 , the resource issuing Dapp stores the first resource information in the blockchain 204 .

[0077] Specifically, the resource issuance Dapp can send a transaction Tx8 containing the first resource information to a node on blockchain 204. The node can execute transaction Tx8 to store the first resource information on blockchain 204. It should be noted that when the aforementioned smart contract C is deployed on blockchain 204, transaction Tx8 can invoke the aforementioned smart contract C, and the first resource information can be specifically stored in the contract state of the aforementioned smart contract C.

[0078] In step S511 , the resource issuing Dapp returns the resource identifier of the resource R1 to the user device 203 .

[0079] In one embodiment, after obtaining resource R1, user User1 may authorize the service platform 201 to view resource R1.

[0080] Specifically, in one embodiment, user User1 can send notification messages to service platform 201 and service platform 202 respectively, authorizing service platform 201 to view resource R1. After receiving the notification message, service platform 201 can obtain the resource summary of resource R1 from service platform 202 and associate resource information such as the resource identifier and resource summary of resource R1 with the second DID for storage.

[0081] In another embodiment, user User1 can authorize resource intercommunication through blockchain 204.

[0082] Specifically, see Figure 6 , which is a timing diagram of the resource interoperability authorization process for resource R1.

[0083] like Figure 6 As shown, first, in step S601, the user device 203 sends a transaction Tx1 to the node of the blockchain 204, in which the user User1 authorizes the business platform 201 to view the resource R1.

[0084] Transaction Tx1 may include authorization information, which may include the resource identifier of resource R1, the first DID of service platform 201, and user User1. Furthermore, the authorization information may include an expiration date, the signature of user User1, and a timestamp generated when the signature was made. The expiration date may be the expiration date of service platform 201's permission to view resource R1.

[0085] When the authorization information includes the signature of user User1, the node of blockchain 204 can verify the signature and execute steps S603 and S605 after the signature is verified.

[0086] In step S603, the node of blockchain 204 sends a notification message to business platform 201 based on transaction Tx1, indicating that user User1 authorizes business platform 201 to view resource R1.

[0087] In step S605, the node of blockchain 204 sends a notification message to business platform 202 based on transaction Tx1, indicating that user User1 authorizes business platform 201 to view resource R1.

[0088] It should be noted that steps S603 and S605 can be executed in parallel or serially, and are not specifically limited here. The notification message may include the authorization information carried in transaction Tx1. Furthermore, the notification message sent to service platform 201 may also include the first hash value of the resource digest of resource R1, the DID and / or IP address of service platform 202, and the like.

[0089] In step S607 , in response to receiving the notification message, the service platform 201 sends a resource summary acquisition request to the service platform 202 , which includes the resource identifier of the resource R1 and the first DID of the service platform 201 .

[0090] Furthermore, the resource summary acquisition request may also include the first hash value and the signature of the service platform 201. The signature may be added using the private key of the service platform 201 (hereinafter referred to as the first private key). The service platform 202 may store the public key of the service platform 201 (hereinafter referred to as the first public key).

[0091] After receiving the resource summary acquisition request, the service platform 202 may execute step S609. In one embodiment, when the resource summary acquisition request includes the signature of the service platform 201, the service platform 202 may verify the signature, for example, based on the first public key, and then execute step S609 after the signature is verified.

[0092] In step S609, the business platform 202 sends a transaction Tx2 to the node of the blockchain 204. The transaction Tx2 includes the resource identifier and the first DID of the resource R1 and is used to perform permission verification on the business platform 201.

[0093] In step S611, the node of blockchain 204 executes transaction Tx2 to verify the authority of business platform 201 based on the above-mentioned platform DID information, and obtains a first verification result.

[0094] As an implementation method, if the first DID of the business platform 201 is included in the platform DID information, it can be determined that the business platform 201 has passed the authority verification, and a first verification result can be generated to represent that the verification has passed; otherwise, it can be determined that the business platform 201 has not passed the authority verification, and a first verification result can be generated to represent that the verification has not passed.

[0095] As another implementation, when the registration information of the business platform 202 includes platform address information of several business platforms that can communicate with the business platform 202, the nodes of the blockchain 204 can perform permission verification on the business platform 201 based on the above-mentioned platform DID information and the platform address information to obtain a first verification result. For example, if the platform address information includes the address information of the business platform 201, and the above-mentioned platform DID information includes the first DID of the business platform, it can be determined that the business platform 201 has passed the permission verification, and a first verification result is generated to indicate that the verification has passed. If the platform address information does not include the address information of the business platform 201 and / or the above-mentioned platform DID information does not include the first DID of the business platform, it can be determined that the business platform 201 has failed the permission verification, and a first verification result is generated to indicate that the verification has failed.

[0096] In step S613 , the node of blockchain 204 sends the first verification result to the business platform 202 .

[0097] In step S615 , in response to the first verification result being verification passed, the service platform 202 obtains the resource digest ciphertext of the resource R1 based on the resource digest acquisition request.

[0098] Specifically, the service platform 202 may obtain the resource summary of the resource R1 based on the resource summary acquisition request, and encrypt the obtained resource summary using the first public key to obtain a resource summary ciphertext.

[0099] In step S617 , the service platform 202 returns a second acquisition result including the resource identifier and resource digest ciphertext of the resource R1 to the service platform 201 .

[0100] In one implementation, after receiving the second acquisition result, the service platform 201 may then execute step S627 to decrypt the resource summary ciphertext.

[0101] In another implementation, business platform 202 may store the second acquisition result in blockchain 204. Business platform 201 may verify the received second acquisition result through blockchain 204 and execute step S627 only after the second acquisition result passes verification. This ensures the correctness of the received second acquisition result. Specifically, this process may be implemented through steps S619-S625.

[0102] In step S619 , the business platform 202 stores the second acquisition result in the blockchain 204 .

[0103] Specifically, the business platform 202 may send a transaction Tx9 including the second acquisition result to a node of the blockchain 204. The node may store the second acquisition result in the blockchain 204 by executing the transaction Tx9.

[0104] In step S621, the business platform 201 sends a transaction Tx3 to the node of the blockchain 204. The transaction Tx3 includes the second acquisition result and is used to verify the second acquisition result.

[0105] It should be noted that when the smart contract C is deployed in the blockchain 204, transactions Tx1, Tx2, Tx3, and Tx9 can all call the smart contract C. Moreover, in step S619, the second acquisition result can be stored in the contract state of the smart contract C.

[0106] In step S623, the node of blockchain 204 executes transaction Tx3, verifies the second acquisition result included in transaction Tx3 based on the stored second acquisition result, and obtains a second verification result.

[0107] In step S625, the node of blockchain 204 returns the second verification result to the business platform 201.

[0108] In step S627, the service platform 201 decrypts the resource summary ciphertext to obtain a decrypted resource summary.

[0109] When steps S619 to S625 are executed, in step S627, the service platform 201 can decrypt the resource summary ciphertext in response to the second verification result being verification passed. Specifically, the service platform 201 can decrypt the resource summary ciphertext using the first private key.

[0110] In step S629 , the service platform 201 associates the second resource information including the resource identifier of the resource R1 and the decrypted resource summary with the second DID of the user User1 and stores the information.

[0111] In one embodiment, when the business platform 202 obtains the resource summary ciphertext of resource R1 based on the resource summary acquisition request, it can also obtain the ciphertext of the attribute field list of resource R1 (hereinafter referred to as the first attribute field list), which can be obtained based on the first public key encryption. Based on this, the second acquisition result can also include the ciphertext of the first attribute field list. Among them, the first attribute field list can, for example, include the various attribute fields of resource R1. Correspondingly, when the business platform 201 decrypts the resource summary ciphertext, it can also decrypt the ciphertext of the first attribute field list, for example, using the first private key to decrypt the ciphertext to obtain the decrypted first attribute field list. Based on this, the second resource information can also include the first attribute field list. Optionally, the second resource information can also include information such as the DID and / or IP address of the business platform 202.

[0112] It should be noted that when the service platform 201 stores the decrypted resource summary, it may segment the resource summary and store the segmented resource summary, which facilitates keyword-based resource search.

[0113] In one embodiment, in response to the first verification result being a successful verification, business platform 202 may store a notification message indicating that user User1 has authorized business platform 201 to view resource R1, or store the authorization information carried in the notification message. This stored information can be used to verify the permissions of business platform 201 when business platform 201 obtains the resource details of resource R1.

[0114] In one embodiment, the business platform 201 may include a search component (hereinafter referred to as the first search component) and the first digital identity basic component as described above, and the business platform 202 may include the second digital identity basic component and resource issuance Dapp as described above. Figure 7The resource interoperability authorization process for resource R1 shown can be implemented through the interaction between the user device 203, the first search component, the first digital identity basic component, the second digital identity basic component, the resource issuance Dapp and the blockchain 204.

[0115] For example, user device 203 may send transaction Tx1 to a node on blockchain 204, indicating that user User1 authorizes business platform 201 to view resource R1. Subsequently, based on transaction Tx1, the node on blockchain 204 may send notification messages regarding this authorization to the first digital identity infrastructure component and the second digital identity infrastructure component. Subsequently, in response to receiving this notification message, the first digital identity infrastructure component may send a resource summary acquisition request to the second digital identity infrastructure component, which includes the resource identifier and first DID of resource R1. Subsequently, the second digital identity infrastructure component may send transaction Tx2 to the node on blockchain 204, which includes the resource identifier and first DID of resource R1 and is used to verify the permissions of business platform 201. The node on blockchain 204 may then execute transaction Tx2 to verify the permissions of business platform 201 based on the platform DID information, obtain a first verification result, and send the first verification result to the second digital identity infrastructure component. In response to the first verification result indicating a successful verification, the second digital identity infrastructure component may forward the resource summary acquisition request to the resource issuing Dapp. Next, the resource issuing Dapp can obtain the resource digest ciphertext of resource R1 based on the resource digest obtain request and return a second obtainment result including the resource identifier and resource digest ciphertext of resource R1 to the second digital identity infrastructure component. The second digital identity infrastructure component can then return the second obtainment result to the first digital identity infrastructure component and store it in blockchain 204. The first digital identity infrastructure component can then send transaction Tx3 to a node on blockchain 204. Transaction Tx3 includes the second obtainment result and is used to verify the second obtainment result. The node on blockchain 204 can then execute transaction Tx3 and verify the second obtainment result based on the stored second obtainment result, obtaining a second verification result and returning the second verification result to the first digital identity infrastructure component. In response to the second verification result being a passed verification, the first digital identity infrastructure component can return the second obtainment result to the first search component. The first search component can then decrypt the resource digest ciphertext to obtain the decrypted resource digest and store the second resource information including the resource identifier and decrypted resource digest of resource R1 in association with the second DID.

[0116] In one embodiment, when the business platform 201 stores a resource summary of the resources owned by user User1 in other business platforms, the business platform 201 can provide keyword-based identity resource search and access capabilities based on the aggregation of user User1's identity resources in different channels, so that the full set of user User1's identity resources can be searched under the premise of user User1's authorization.

[0117] Next, combine Figure 7 Describes the resource search process.

[0118] See Figure 7 , which is a timing diagram of the resource data processing method in the embodiment of this specification.

[0119] like Figure 7 As shown, first, in step S701, the user device 203 sends a resource search request of the user User1 to the service platform 201, and the resource search request includes a search keyword.

[0120] Specifically, when user User1 has a resource search requirement, he or she may send a resource search request including a search keyword to the service platform 201 through the user device 203 .

[0121] In step S703 , the service platform 201 searches for a target resource abstract that matches the search keyword among several stored resource abstracts associated with the user User1 .

[0122] Specifically, the service platform 201 may search for a target resource abstract that matches the search keyword among several stored resource abstracts associated with the second DID of the user User1.

[0123] In step S705 , in response to the target resource summary being the resource summary of the resource R1 owned by the user User1 in the service platform 202 , the service platform 201 sends a resource details acquisition request for the resource R1 to the service platform 202 .

[0124] The resource detail acquisition request may include the resource identifier of resource R1 and the first DID of service platform 201. Furthermore, the resource detail acquisition request may also include at least one of the following: the first hash value of the resource summary of resource R1, the first attribute field list of resource R1, and the signature of service platform 201.

[0125] In step S707 , the service platform 202 confirms whether the service platform 201 has the viewing authority for the resource R1 .

[0126] For example, based on the resource identifier of resource R1 and the first DID of service platform 201, service platform 202 can search locally for a notification message indicating that user User1 has authorized service platform 201 to view resource R1, or for the authorization information contained in the notification message. If the message is found, service platform 201 is determined to have permission to view resource R1. Service platform 202 can then proceed to step S709.

[0127] In one embodiment, when the resource details acquisition request includes the signature of the service platform 201, the service platform 202 may also verify the signature. After confirming that the service platform 201 has the viewing permission for the resource R1 and the signature passes the verification, the service platform 202 may proceed to step S709.

[0128] In step S709 , the service platform 202 obtains the ciphertext of the resource details of the resource R1 based on the resource details acquisition request.

[0129] Specifically, service platform 202 can obtain resource details for resource R1 based on the resource details acquisition request. Service platform 202 can then encrypt the resource details using the first public key of service platform 201 to obtain resource details ciphertext. The obtained resource details can include a resource details key-value pair for resource R1, and the resource details ciphertext can include the ciphertext of the resource details key-value pair.

[0130] Furthermore, when the resource detail acquisition request also includes a first attribute field list, the acquired resource details may specifically include a second attribute field list and a resource detail key-value pair corresponding to the second attribute field list. The resource detail ciphertext may include the ciphertext of the second attribute field list and the ciphertext of the resource detail key-value pair. The second attribute field list is composed of at least some of the attribute fields in the first attribute field list. By employing the resource detail acquisition process described herein, the business platform 202 can selectively disclose resource details based on its own security rules.

[0131] In step S711 , the service platform 202 returns a first acquisition result including the resource identifier and the ciphertext of the resource details of the resource R1 to the service platform 201 .

[0132] In one embodiment, the business platform 202 may also store the first acquisition result. For example, the business platform 202 may store the first acquisition result in the blockchain 204 by executing step S713.

[0133] Specifically, in step S713, business platform 202 may send transaction Tx10 including the first acquisition result to the node of blockchain 204. The node may execute transaction Tx10 to store the first acquisition result in blockchain 204. It should be noted that when the aforementioned smart contract C is deployed in blockchain 204, transaction Tx10 may invoke the aforementioned smart contract C, and the first acquisition result may be specifically stored in the contract state of the aforementioned smart contract C.

[0134] In step S715 , the service platform 201 decrypts the ciphertext of the resource details to obtain the decrypted resource details.

[0135] Specifically, the service platform 201 may use its own first private key to decrypt the resource details ciphertext to obtain the decrypted resource details.

[0136] In step S717 , the service platform 201 returns the decrypted resource details to the user device 203 , so as to provide the decrypted resource details to the user User1 .

[0137] In one embodiment, the business platform 201 may include a business application (hereinafter referred to as the first business application) and the first search component and the first digital identity basic component as described above, and the business platform 202 may include the second digital identity basic component and the resource issuance Dapp as described above. Figure 8 The resource data processing process shown can be implemented through the interaction between the user device 203, the first business application, the first search component, the first digital identity basic component, the second digital identity basic component, the resource issuance Dapp and the blockchain 204.

[0138] For example, user User1 can send a resource search request including search keywords to the first business application via user device 203. The resource search request then includes search keywords. The first business application can then forward the resource search request to the first search component. The first search component can then search for a target resource summary that matches the search keywords among several stored resource summaries associated with user User1. In response to the target resource summary being the summary of resource R1 owned by user User1 on business platform 202, the first search component can then send a resource detail retrieval request for resource R1 to the second digital identity infrastructure component via the first digital identity infrastructure component. The second digital identity infrastructure component can then confirm whether business platform 201 has permission to view resource R1. Once this is confirmed, the resource detail retrieval request is forwarded to the resource issuing Dapp. The resource issuing Dapp can then retrieve the ciphertext of the resource details for resource R1 based on the resource detail retrieval request and return a first retrieval result, including the resource identifier and ciphertext of the resource details for resource R1, to the first digital identity infrastructure component via the second digital identity infrastructure component. In addition, the second digital identity infrastructure component may also store the first acquisition result in blockchain 204. The first digital identity infrastructure component may return the first acquisition result to the first search component. The first search component may then decrypt the resource detail ciphertext to obtain the decrypted resource details and return the decrypted resource details to the first service application. The first service application may then return the decrypted resource details to the user device 203.

[0139] Figure 7 The solution provided by the corresponding embodiment can provide keyword-based identity resource search and access capabilities based on the aggregation of identity resources of the same user in different channels, so that the full set of identity resources of the user can be searched in any channel under the premise of user authorization.

[0140] As described above, the solution provided by the embodiments of this specification can be achieved through the digital identity infrastructure + digital identity scaffolding + blockchain, defining a VC issuance Dapp and an identity authentication Dapp to achieve global identity mutual recognition and unification, and a resource issuance Dapp to achieve resource visibility and circulation. This achieves: a decentralized technical architecture, eliminating the need to select a centralized identity resource aggregation node, allowing various institutions and entities to join the network in a loosely coupled manner; the details of distributed identity resources are all stored locally on each node, and after dual authorization by users and institutions, details can be searched through resource summaries, enabling on-demand disclosure of field-level identity resource information; because multi-subject collaboration is achieved based on blockchain, the entire process can be guaranteed to be trustworthy and tamper-proof. In summary, the definition and authentication of identity through the VC issuance Dapp and the identity authentication Dapp, as well as the visibility and flow of resources through the resource issuance Dapp, can support a cross-subject identity resource search engine and realize on-demand disclosure capabilities from summaries to details, thereby truly making users' global identity resources searchable and accessible.

[0141] Figure 8 This is a schematic diagram of the structure of the resource data processing device in the embodiment of this specification. The device can be applied to any service platform (hereinafter referred to as the first service platform).

[0142] like Figure 8 As shown, the resource data processing device 800 in the embodiment of this specification may include: a receiving unit 801, a searching unit 802, a sending unit 803 and a decryption unit 804. The receiving unit 801 is configured to receive a resource search request from a first user, the resource search request including a search keyword; the searching unit 802 is configured to search for a target resource summary that matches the search keyword in a plurality of stored resource summaries associated with the first user, the plurality of resource summaries including resource summaries of resources owned by the first user in other business platforms, the resource summaries being obtained by the first business platform from the other business platforms after authorization by the first user; the sending unit 803 is configured to, in response to the target resource summary being a resource summary of a first resource owned by the first user in the second business platform, send a request to the second business platform. The platform sends a resource detail acquisition request, which includes the first decentralized identity identifier DID of the first business platform and the resource identifier of the first resource; the receiving unit 801 is also configured to receive the first acquisition result returned by the second business platform, which is sent by the second business platform after confirming that the first business platform has viewing authority for the first resource, and includes the resource identifier and the resource detail ciphertext of the first resource; the decryption unit 804 is configured to decrypt the resource detail ciphertext to obtain the decrypted resource details; the sending unit 803 is also configured to provide the decrypted resource details to the first user.

[0143] exist Figure 8For the corresponding device embodiments, reference may be made to the relevant descriptions in the relevant method embodiments above, which will not be repeated here.

[0144] The embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed in a computer, the computer is caused to execute the resource data processing method described in the above method embodiments.

[0145] An embodiment of this specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the resource data processing method described in the above method embodiment is implemented.

[0146] The embodiments of this specification also provide a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the resource data processing method described in the above method embodiments.

[0147] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0148] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0149] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0150] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0151] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0152] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0153] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0154] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

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

[0156] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0157] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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, graphene 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.

[0158] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

[0160] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0161] The foregoing description is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. Those skilled in the art will appreciate that various modifications and variations of one or more embodiments of this specification are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification are intended to be included within the scope of the claims.

Claims

1. A resource data processing method, comprising: The first service platform receives a resource search request from a first user, where the resource search request includes a search keyword; The first service platform searches for a target resource summary that matches the search keyword from a plurality of stored resource summaries associated with the first user, wherein the plurality of resource summaries include resource summaries of resources owned by the first user on other service platforms, and the resource summaries are obtained by the first service platform from the other service platforms after authorization by the first user; In response to the target resource summary being the resource summary of the first resource owned by the first user in the second service platform, the first service platform sends a resource detail acquisition request to the second service platform, where the resource detail acquisition request includes a first decentralized identity identifier (DID) of the first service platform and a resource identifier of the first resource; After confirming that the first business platform has the viewing permission for the first resource, the second business platform obtains the ciphertext of the resource details of the first resource based on the resource details acquisition request, and returns a first acquisition result including the resource identifier and the ciphertext of the resource details to the first business platform; The first service platform decrypts the resource detail ciphertext to obtain decrypted resource details, and provides the decrypted resource details to the first user.

2. The method according to claim 1, wherein The first business platform also stores a first attribute field list of the first resource, the resource detail acquisition request also includes the first attribute field list, the resource detail ciphertext includes the ciphertext of the second attribute field list of the first resource, and the ciphertext of the resource detail key-value pairs corresponding to the second attribute field list, wherein the second attribute field list is composed of at least part of the attribute fields in the first attribute field list.

3. The method according to claim 1, wherein The second service platform stores the first public key of the first service platform; The obtaining of the ciphertext of the resource details of the first resource based on the resource details obtaining request includes: Acquiring resource details of the first resource based on the resource details acquisition request; Encrypting the obtained resource details using the first public key to obtain the resource details ciphertext; Decrypting the resource details ciphertext includes: The resource detail ciphertext is decrypted using the first private key of the first business platform.

4. The method according to claim 1, further comprising: The second business platform stores the first acquisition result in the blockchain.

5. The method according to claim 4, wherein The first resource is issued by a resource issuing agency to the first user in the second business platform. The blockchain stores first resource information of the first resource. The first resource information includes the resource identifier, the second DID of the first user, the first hash value of the resource summary of the first resource, the third DID of the resource issuing agency, and the platform DID information provided by the resource issuing agency. The platform DID information includes the DIDs of several business platforms that can view the first resource.

6. The method according to claim 5, wherein: Before the first service platform receives the resource search request from the first user, the method further includes: The node of the blockchain receives a first transaction in which the first user authorizes the first business platform to view the first resource, and sends a notification message related to the authorization to the first business platform and the second business platform based on the first transaction, wherein the first transaction and the notification message both include the resource identifier, the first DID, and the second DID; In response to receiving the notification message, the first service platform sends a resource summary acquisition request to the second service platform, where the resource summary acquisition request includes the resource identifier and the first DID; The second business platform sends a second transaction to the node of the blockchain, where the second transaction includes the resource identifier and the first DID and is used to verify the authority of the first business platform; The node of the blockchain performs permission verification on the first business platform based on the platform DID information by executing the second transaction, obtains a first verification result, and returns the first verification result to the second business platform; In response to the first verification result being a passed verification, the second service platform obtains the resource digest ciphertext of the first resource based on the resource digest acquisition request, and returns a second acquisition result including the resource identifier and the resource digest ciphertext to the first service platform; The first service platform decrypts the resource summary ciphertext to obtain a decrypted resource summary, and associates the second resource information including the resource identifier and the decrypted resource summary with the second DID for storage.

7. The method according to claim 6, wherein: The blockchain also stores registration information of the second business platform, wherein the registration information includes platform address information of several business platforms that can communicate with the second business platform; The performing authority verification on the first service platform based on the platform DID information includes: Based on the platform DID information and the platform address information, the first service platform is subjected to permission verification.

8. The method according to claim 6, wherein: When obtaining the resource digest ciphertext of the first resource based on the resource digest acquisition request, the method further includes: Acquire the ciphertext of the first attribute field list of the first resource; wherein the second acquisition result also includes the ciphertext of the first attribute field list; When decrypting the resource summary ciphertext, the method further includes: The ciphertext of the first attribute field list is decrypted to obtain the decrypted first attribute field list; wherein the second resource information also includes the first attribute field list.

9. The method according to claim 6, further comprising: The second business platform stores the second acquisition result in the blockchain; In response to receiving the second acquisition result, the first business platform sends a third transaction to a node of the blockchain, where the third transaction includes the second acquisition result and is used to verify the second acquisition result; The node of the blockchain executes the third transaction, verifies the second acquisition result included in the third transaction based on the stored second acquisition result, obtains a second verification result, and returns the second verification result to the first business platform; The first service platform decrypts the resource summary ciphertext, including: In response to the second verification result being a verification pass, the first service platform decrypts the resource summary ciphertext.

10. The method according to claim 6, wherein: A smart contract for resource intercommunication processing is deployed in the blockchain, and both the first transaction and the second transaction call the smart contract.

11. The method according to claim 6, wherein: The second business platform includes a resource issuance Dapp associated with the resource issuance agency, and the first resource is specifically issued to the first user by the resource issuance Dapp.

12. The method according to claim 11, wherein Before the node of the blockchain receives the first transaction of the first user authorizing the first business platform to view the first resource, the method further includes: The resource issuance Dapp receives a resource application request from the first user for the first resource, where the resource application request includes the first identity information of the first user; When the resource issuance Dapp confirms that the first user has passed identity authentication and obtained the second DID based on the first identity information, it generates and stores third resource information of the first resource, where the third resource information includes the resource identifier, resource summary, resource details, the second DID, and the third DID; The resource issuance Dapp generates the first resource information, stores the first resource information in the blockchain, and returns the resource identifier to the first user.

13. The method according to claim 12, wherein: The second business platform also includes an identity issuance Dapp associated with an identity issuance authority; Before the resource issuance Dapp receives the resource application request for the first resource from the first user, the method further includes: The identity issuance Dapp receives the real-name authentication request of the first user, generates the second DID for the first user after the first user is authenticated based on the real-name authentication request, and returns the second DID to the first user.

14. The method according to claim 11, wherein The first business platform includes a first search component and a first digital identity basic component, and the second business platform also includes a second digital identity basic component that can communicate with the first digital identity basic component. The resource issuance Dapp is deployed in the second digital identity basic component.

15. A resource data processing method, applied to a first business platform, comprising: receiving a resource search request from a first user, wherein the resource search request includes a search keyword; Searching for a target resource summary that matches the search keyword from among several stored resource summaries associated with the first user, wherein the several resource summaries include resource summaries of resources owned by the first user on other service platforms, the resource summaries being obtained by the first service platform from the other service platforms after authorization by the first user; In response to the target resource summary being the resource summary of a first resource owned by the first user in the second service platform, sending a resource detail acquisition request to the second service platform, the resource detail acquisition request including a first decentralized identity identifier (DID) of the first service platform and a resource identifier of the first resource; receiving a first acquisition result returned by the second service platform, wherein the first acquisition result is sent by the second service platform after confirming that the first service platform has viewing permission for the first resource and includes the resource identifier and a ciphertext of resource details of the first resource; The resource detail ciphertext is decrypted to obtain decrypted resource details, and the decrypted resource details are provided to the first user.

16. A resource data processing device, applied to a first service platform, comprising: A receiving unit configured to receive a resource search request from the first user, wherein the resource search request includes a search keyword; a search unit configured to search for a target resource summary that matches the search keyword from a plurality of stored resource summaries associated with the first user, the plurality of resource summaries including resource summaries of resources owned by the first user on other service platforms, the resource summaries being obtained by the first service platform from the other service platforms after authorization by the first user; a sending unit configured to, in response to the target resource summary being a resource summary of a first resource owned by the first user in the second service platform, send a resource detail acquisition request to the second service platform, the resource detail acquisition request including a first decentralized identity identifier (DID) of the first service platform and a resource identifier of the first resource; The receiving unit is further configured to receive a first acquisition result returned by the second service platform, the first acquisition result being sent by the second service platform after confirming that the first service platform has viewing permission for the first resource, and including the resource identifier and a ciphertext of resource details of the first resource; a decryption unit configured to decrypt the resource details ciphertext to obtain decrypted resource details; The sending unit is further configured to provide the decrypted resource details to the first user.

17. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to claim 15.

18. A computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to claim 15 is implemented.

Images