Decentralized identity cross-domain analysis protocol

Abstract

The invention discloses a decentralized identity cross-domain analysis protocol, and relates to the technical field of block chains. Comprising the following steps: step 1, a data preparation stage; 2, a cross-domain request and response stage; and 3, an analysis result verification stage. According to the decentralized identity cross-domain analysis protocol, the consistency, correctness and real-time performance of data in the cross-domain analysis process are ensured through the combination of the edge node and the block chain, the root hash of the outer-domain block chain is periodically synchronized through the edge node, and the root hash is written into the local-domain block chain, so that an intra-domain user can verify the analysis result of the outer-domain DID identifier, and the user experience is improved. According to the method, the credibility and the non-repudiation of a cross-domain analysis result are ensured, a cache structure based on TTL and LRU is designed, and dynamic updating is performed in combination with block chain root hash and local cache data, so that the analysis efficiency is improved, the frequency of a cross-domain request is reduced, and the real-time performance and the accuracy of the cache data are ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain, and in particular to a decentralized identity cross-domain resolution protocol. Background Art

[0002] Network identity authentication systems (referred to as identity authentication systems) can be divided into three categories according to different system architectures: centralized, distributed, and decentralized. A decentralized identity authentication system refers to a system with multiple authentication servers and no central server, and its goal is to solve the defects of distributed identity authentication systems. Patent CN109218319A discloses an identity authentication system and method based on blockchain. The method combines blockchain with identity authentication, and implements a completely decentralized identity authentication system by designing a key module, an identity authentication module, and a service module in the system. The system can solve the problem of central servers being attacked or paralyzed in distributed systems, and improve the stability of the system, but the system still has the following shortcomings: 1) The user's identity information credentials are completely dependent on the user's private key. Once the private key is stolen, there is a risk of identity information being misused.

[0003] The invention patent with announcement number CN113259311A discloses a decentralized identity authentication system based on blockchain, including multiple server nodes with the same functions and powers, namely authentication nodes. Each authentication node includes: identity information collection module, real-name authentication module, data storage module, identity information signature module and access verification module. Mainly through the identity information collection module, real-name authentication module and identity information signature module, a higher security level "private key + biometrics + security factor" user identity information credential can be generated to reduce the risk of user identity being misused.

[0004] However, since nodes outside the domain cannot access blockchain nodes within the domain, the decentralized identity resolution verification scheme cannot verify the correctness and real-time nature of the identity resolution results by verifying the Merkle proof. Currently, there are a variety of cross-domain resolution schemes for decentralized identities, but they all rely on centralized cross-domain resolvers, which destroys the decentralized nature of decentralized identities. Existing schemes mostly rely on centralized resolvers, consortium chains, or relay bridge mechanisms, but there are centralized trust risks, low efficiency, and security risks. Summary of the invention

[0005] In view of the deficiencies of the prior art, the present invention provides a decentralized identity cross-domain resolution protocol to solve the existing problems.

[0006] To achieve the above objectives, the present invention is implemented through the following technical solutions: a decentralized identity cross-domain resolution protocol, comprising the following steps:

[0007] Step 1: Data preparation phase: timely process the user's DID identifier and DID document registration and modification requests. User Ub in the Dp domain calls BCp.Set(DID,DIDDoc) to update the DID document information on the blockchain based on the update of his or her identity information.

[0008] Step 2, cross-domain request and response phase: User Ub finds the edge node ENi responsible for the external domain, initiates an identity resolution request for the external domain, initiates a cross-domain resolution request Ub.request(ENi,{BCq,DIDs}), and waits for a response;

[0009] Step 3: Parsing result verification phase: The user initiates a request, BCp.Get(BCq,rootHash,blockNumber)→rootHash, to obtain the parsing result and the root hash value of BCq from the blockchain in the domain.

[0010] Preferably, the edge node set {EN1, ..ENn} in the domain in step 1 periodically synchronizes the root hash of the external domain blockchain that the node is responsible for, and synchronizes the corresponding root hash to the blockchain of the domain. Assuming that ENi has the authority to access domain Dq, ENi should periodically initiate a request ENi.request(BCq,QueryLatestRootHash)→{BlockNumber,rootHash}, and call BCp.Set to update the root hash of domain Dq on the blockchain.

[0011] Preferably, in step 2, the edge node responds to the user's identity resolution request, and the resolution result is {DIDs, DIDDocs, MerkleProofs, SigENi}. The DID document and Merkle proof field of the response should be signed with the public key corresponding to the DID identifier of the edge node ENi to ensure the non-repudiation of the resolution result.

[0012] Preferably, in step 2, cross-domain identity resolution is accelerated by setting a cache on the edge node.

[0013] Preferably, in step three, the user first verifies whether the DID document in the parsing result has expired, whether it corresponds to the DID identifier, and whether it has the signature of the edge node. After the verification is passed, the Merkle proof of the parsing result is verified using the obtained root hash value to ensure the integrity of the parsing result.

[0014] Preferably, the structure of the node cache record in step three includes the following key fields: DID identifier, DID document, Merkle Proof, block number, TTL (Time To Live), and LRU (Least Recently Used).

[0015] Preferably, the structure of the node cache record also includes storing Merkle Proof and corresponding block number, so that users can verify the integrity of the parsing results.

[0016] Preferably, the TTL of the parsing result in step three is determined by the minimum value of the expiration time set in the DID document, the cache record TTL specified between the two domains, and the globally set TTL.

[0017] Preferably, the present invention further discloses an identity resolution cache update algorithm, including an identity resolution cache update operation:

[0018] Input: cache table IDCache, the latest resolved identity set RDIDs, the latest cross-domain resolved identity record set Rs, the block number Bn stored on the blockchain, the discard delay t, and the IDCache capacity threshold V

[0019] Output: identity set UDIDs to be updated

[0020] Output: identity set UDIDs to be updated, new discard delay t

[0021]

[0022]

[0023] The present invention provides a decentralized identity cross-domain resolution protocol. Compared with the prior art, it has the following beneficial effects:

[0024] 1. The decentralized identity cross-domain resolution protocol ensures the consistency, correctness and real-time of data in the cross-domain resolution process through the combination of edge nodes and blockchains. It regularly synchronizes the root hash of the external domain blockchain through edge nodes and writes it into the local domain blockchain to ensure that users in the domain can verify the resolution results of the external DID identifier, ensuring the credibility and non-repudiation of the cross-domain resolution results. It designs a cache structure based on TTL and LRU, combines the blockchain root hash and local cache data for dynamic updates to improve resolution efficiency, reduce the frequency of cross-domain requests, and ensure the real-time and accuracy of cached data. Through voting mechanisms, cross-validation and disguised queries, malicious nodes are discovered and punished in a timely manner to prevent them from uploading incorrect root hashes or returning expired resolution results, thereby ensuring the security and stability of the system.

[0025] 2. The decentralized identity cross-domain resolution protocol adopts a consistent hashing algorithm to evenly distribute the resolution tasks of edge nodes in the blockchain to a hash ring, thereby dynamically managing the resolution range of nodes, ensuring node load balancing and improving system scalability. By digitally signing the cross-domain resolution request results of the edge nodes, the non-repudiation and security of the resolution results are ensured, so that users can verify the source and integrity of the resolution results. A distributed cross-domain resolution request processing method is designed, allowing multiple edge nodes to participate in the resolution at the same time, and verifying the accuracy of the data by comparing multiple resolution results, thereby improving the fault tolerance and security of the resolution process. At the same time, multi-level TTL management is introduced in the cache records. By combining the lifespan of the DID document, the TTL setting of the cross-domain protocol and the global TTL, the real-time and validity of the data are ensured, and the impact of expired data on the resolution results is avoided. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a schematic diagram of the process of the present invention;

[0027] Figure 2 Schematic diagram of the cross-domain identity resolution protocol of the present invention. DETAILED DESCRIPTION

[0028] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0029] See also Figure 1-2 , the present invention provides two technical solutions:

[0030] The first implementation method: a decentralized identity cross-domain resolution protocol, comprising the following steps:

[0031] Step 1: Data preparation phase: timely process the user's DID identifier and DID document registration and modification requests. User Ub in the Dp domain calls BCp.Set(DID,DIDDoc) to update the DID document information on the blockchain based on the update of his or her identity information.

[0032] The set of edge nodes in the domain {EN1, ..ENn} should regularly synchronize the root hash of the external domain blockchain that the node is responsible for, and synchronize the corresponding root hash to the blockchain of the domain. Assuming that ENi has the authority to access domain Dq, ENi should regularly initiate requests ENi.request(BCq,QueryLatestRootHash)→{BlockNumber,rootHash} and call BCp.Set(BCq,rootHash) to update the root hash of domain Dq on the blockchain.

[0033] Step 2, cross-domain request and response phase: User Ub finds the edge node ENi responsible for the external domain, initiates an identity resolution request outside the domain, starts a cross-domain resolution request Ub.request(ENi,{BCq,DIDs}), and waits for a response.

[0034] The edge node forwards the user’s identity resolution request, ENi.request(BCq,{DIDs})→{DIDs,DIDDocs,MerkleProofs}, to perform cross-domain identity resolution.

[0035] The edge node responds to the user's identity resolution request, and the resolution result is {DIDs, DIDDocs, MerkleProofs, SigENi}. The DID document and Merkle proof fields of the response are signed with the public key corresponding to the DID identifier of the edge node ENi to ensure the non-repudiation of the resolution result.

[0036] Step 3: Parsing result verification phase: User initiates a request.

[0037] BCp.Get(BCq,rootHash,blockNumber)→rootHash, get the parsing result and the root hash value of BCq from the blockchain in the domain.

[0038] The user first verifies whether the DID document in the parsing result has expired, whether it corresponds to the DID identifier, and whether it has the signature of the edge node. After the verification is passed, the Merkle proof of the parsing result is verified using the obtained root hash value to ensure the integrity of the parsing result.

[0039] To speed up cross-domain identity resolution, setting up a cache on edge nodes is an inevitable measure. However, in the scenario of cross-domain identity resolution, the node may return outdated resolution results, or the node cache may be polluted and return incorrect resolution results, destroying the consistency of the resolution protocol.

[0040] To ensure the consistency of the resolution results, the structure of the node cache record should include the following key fields: DID identifier, DID document, Merkle Proof, block number, TTL (Time To Live), and LRU (Least Recently Used). In addition to the DID identifier and its corresponding DID document, the Merkle Proof and the corresponding block number need to be stored so that users can verify the integrity of the resolution results.

[0041] The TTL of the resolution result is determined by the minimum value of the expiration time set in the DID document, the cache record TTL stipulated between the two domains, and the globally set TTL, in order to ensure real-time update of data as much as possible. Each record also records the time of its last use, which helps to evaluate the activity of the data. Combining the TTL and LRU fields, the system can decide which data should be eliminated after being outdated and which needs to be updated, and determine the replacement priority of data when the cache capacity is limited.

[0042] Second implementation method: Based on the above method, the present invention also discloses an identity resolution cache update algorithm, which combines the latest root hash stored on the blockchain and the local cache data to actively update the local cache.

[0043] Input: cache table IDCache, the latest resolved identity set RDIDs, the latest cross-domain resolved identity record set Rs, the block number Bn stored on the blockchain, the discard delay t, and the IDCache capacity threshold V

[0044] Output: identity set UDIDs to be updated

[0045] Output: identity set UDIDs to be updated, new discard delay t

[0046]

[0047] end if;

[0048] if r.LRU+t>Bn:

[0049] put r.DID into UDIDs;

[0050] end if;

[0051] end for;

[0052] return UDIDs,t.

[0053] The above algorithm will be called after each block is on the chain, and the cached resolution results will be actively updated according to the returned UDIDs. In addition to active updates, the cache will also be passively updated. A cross-domain resolution request will involve two edge nodes inside and outside the domain at the same time. For example, in a cross-domain resolution request, after ENp of domain Dp requests identity resolution DIDt from ENq of Dq, when the DID document information corresponding to DIDt changes, ENp will actively initiate an update request to ENq to update the cached information of DIDt. The two update strategies of active and passive reduce the probability of cross-domain requests during resolution, improve resolution efficiency, and ensure the timeliness and accuracy of cached data.

[0054] Meanwhile, the contents not described in detail in this specification belong to the prior art known to those skilled in the art, and the model parameters of each electrical appliance are not specifically limited, and conventional equipment can be used.

[0055] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0056] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A decentralized identity cross-domain resolution protocol, characterized in that: The following steps are involved: Step 1: Data preparation stage: timely process the user's DID identifier and DID document registration and modification requests. User Ub in the Dp domain calls BCp.Set to update the DID document information on the blockchain based on the update of his or her identity information. Step 2, cross-domain request and response phase: User Ub finds the edge node ENi responsible for the external domain, initiates an identity resolution request for the external domain, initiates a cross-domain resolution request Ub.request, and waits for a response; Step 3: Parsing result verification phase: The user initiates a request, BCp.Get→rootHash, to obtain the parsing result and the root hash value of BCq from the blockchain within the domain.

2. A decentralized identity cross-domain resolution protocol according to claim 1, characterized in that: The edge node set {EN1, ..ENn} in the domain in step 1 periodically synchronizes the root hash of the external domain blockchain that the node is responsible for, synchronizes the corresponding root hash to the blockchain of the domain, and calls BCp.Set to update the root hash of the Dq domain on the blockchain.

3. A decentralized identity cross-domain resolution protocol according to claim 1, characterized in that: In step 2, the edge node responds to the user's identity resolution request, and the resolution result is {DIDs, DIDDocs, MerkleProofs, SigENi}. The DID document and Merkle proof fields of the response should be signed with the public key corresponding to the DID identifier of the edge node ENi to ensure the non-repudiation of the resolution result.

4. A decentralized identity cross-domain resolution protocol according to claim 1, characterized in that: In the step 2, a cache is set on the edge node to speed up the cross-domain identity resolution.

5. A decentralized identity cross-domain resolution protocol according to claim 1, characterized in that: In step three, the user first verifies whether the DID document in the parsing result has expired, whether it corresponds to the DID identifier, and whether it has the signature of the edge node. After the verification is passed, the Merkle proof of the parsing result is verified using the obtained root hash value to ensure the integrity of the parsing result.

6. A decentralized identity cross-domain resolution protocol according to claim 1, characterized in that: The structure of the node cache record in step 3 includes the following key fields: DID identifier, DID document, Merkle Proof, block number, TTL, and LRU.

7. A decentralized identity cross-domain resolution protocol according to claim 6, characterized in that: The structure of the node cache record also includes storing Merkle Proof and the corresponding block number, so that users can verify the integrity of the parsing results.

8. A decentralized identity cross-domain resolution protocol according to claim 1, characterized in that: The TTL of the parsing result in step 3 is determined by the minimum value of the expiration time set in the DID document, the cache record TTL specified between the two domains, and the globally set TTL.

Images