Decentralized identity strong binding and security recovery method and system

Abstract

The application discloses a kind of decentralized identity strong binding and safe recovery method, including S1: deploying smart contract on blockchain network;S2: user generates main public-private key pair through smart contract, and smart contract allocates unique decentralized identifier for main public key, and it is set to unverified state, while storing the association of decentralized identifier and main public key;S3: for the decentralized identifier of unverified state, user submits binding assertion to smart contract for validity verification, and after passing verification, it is converted into verified state and is authorized.The application also discloses a kind of decentralized identity strong binding and safe recovery system.The application can enable smart contract to realize the operation of corresponding function, without intervention of centralized agency in whole process, both retains the self-controllable characteristics of decentralized identity, and realizes the unity of security, public credibility and ease of use through multi-party authoritative endorsement and strict verification mechanism.

Description

Technical Field

[0001] This invention relates to the fields of blockchain technology and information security technology, and in particular to a decentralized identity strong binding and security recovery method and system. Background Technology

[0002] Decentralized identity systems, as an emerging paradigm for identity management, offer several advantages over traditional centralized identity systems. In traditional centralized systems, user identities are centrally controlled by a single institution, posing a single point of failure risk and increasing the risk of data misuse and privacy breaches. Users cannot truly have control over their identities. In contrast, decentralized identity systems rely on secure and controllable decentralized identifiers (DIDs), allowing users to manage their identity information autonomously, and offering advantages such as high privacy protection, high security, and trusted communication. However, existing decentralized identity systems still face two key challenges in their implementation:

[0003] First, the identity binding mechanism is not strong enough. Currently, the process of linking a decentralized identifier (DID) with a user's real physical identity usually relies on easily compromised verification methods such as mobile phone numbers and email addresses. This weak binding relationship is easily cracked and forged, thus failing to meet the security requirements of application scenarios such as finance and government affairs, which have extremely high requirements for identity credibility.

[0004] Secondly, the security recovery mechanism has design flaws. Traditional recovery solutions mostly rely on a single private key backup or appeal mode. Once the private key is lost, users face the risk of permanent loss of their identity and associated digital assets. Although there are recovery mechanisms based on social relationships to enhance recoverability, the ordinary contacts on which these mechanisms rely often have inconsistent reliability, are vulnerable to collusive attacks, and are difficult to reach in emergencies, resulting in bottlenecks in both security and usability. Summary of the Invention

[0005] The main objective of this invention is to propose a decentralized identity strong binding and secure recovery method and system, which aims to solve the technical problems faced by existing decentralized identity systems, such as insufficient identity binding mechanism strength and defects in security recovery mechanism.

[0006] To achieve the above objectives, the decentralized identity strong binding and secure recovery method proposed in this invention includes the following steps:

[0007] S1: Deploy a smart contract on a blockchain network. The smart contract has a built-in registration function, a DID life state set, a state transition rule, a list of trusted assertors, and assertion verification logic. The DID life state set includes unverified state and verified state.

[0008] S2: The user generates a master public key pair by calling the registration function of the smart contract. The smart contract assigns a unique decentralized identifier to the master public key and sets the initial state of the decentralized identifier to an unverified state, while storing the association between the decentralized identifier and the master public key.

[0009] S3: For decentralized identifiers in an unverified state, users submit multiple binding assertions to the smart contract. The smart contract performs full-process validity verification on each binding assertion. When the number of verified binding assertions reaches a preset threshold M, the decentralized identifier is converted from an unverified state to a verified state, and the decentralized identifier is granted full operation permissions.

[0010] Optionally, the following steps are also included:

[0011] S4: The smart contract also has a built-in recovery startup function. The DID life state set also includes a recovery state. For the decentralized identifier in the verified state, when the user's master private key is lost, the smart contract's recovery startup function is called through a preset recovery method. After the smart contract verifies the user's recovery permission, it changes the decentralized identifier from the verified state to the recovery state and starts the high-risk operation freezing mechanism.

[0012] S5: For a decentralized identifier in the recovery process, the user submits multiple recovery assertions to the smart contract. The smart contract performs full-process validity verification on each recovery assertion. When the number of verified recovery assertions reaches a preset threshold K, the master public key associated with the decentralized identifier is updated to a new public key, the decentralized identifier is changed from the recovery state to the verified state, and the high-risk operation freeze is lifted.

[0013] Optionally, in step S4, the high-risk operation freezing mechanism includes prohibiting decentralized identifiers from performing transfers, permission changes, and asset staking operations.

[0014] Optionally, the following steps are also included:

[0015] S6: The DID life state set also includes a revoked state. When a user initiates an identity revocation request, the smart contract sets the corresponding decentralized identifier to a revoked state and terminates all operation permissions of the decentralized identifier.

[0016] Optionally, the deployment process of the smart contract in step S1 includes:

[0017] S11: Use a programming language to write smart contract code that includes a registration function, a DID life state set, state transition rules, a list of trusted assertors, and assertion verification logic;

[0018] S12: Compile the smart contract code into bytecode executable by the blockchain virtual machine;

[0019] S13: The bytecode is sent to the blockchain network by creating a transaction. After the blockchain node in the blockchain network executes the transaction, it creates a contract account and stores the contract code.

[0020] S14: Record the unique blockchain address corresponding to the contract account. Users and applications can call contract functions through this unique blockchain address.

[0021] Optionally, in step S2, the smart contract constructs a "DID-identity information" mapping relationship through a data structure, wherein the identity information includes the current life status of the DID, the associated public key, and the recovery configuration parameters.

[0022] Optionally, the full-process validity verification of the bound assertions in step S3 includes:

[0023] S31: Extract the issuer DID from the binding assertion, and query the corresponding public key in the smart contract's preset list of trusted assertors. If the key is not found, the verification fails.

[0024] S32: Remove the signature field from the binding assertion, reorganize the remaining fields in a preset order. The remaining fields include the issuer DID, the assertion object DID, the assertion content, and the assertion validity period, and calculate the hash value.

[0025] S33: Call the cryptographic verification function built into the blockchain virtual machine, input the hash value, the signature in the binding assertion, and the public key of the issuing party obtained from the query, to verify the authenticity of the signature;

[0026] S34: Verify the consistency between the assertion object DID and the user DID of the current operation, whether the assertion validity period has expired, and whether the assertion type is a bound assertion. If all verifications pass, the bound assertion verification is valid.

[0027] Optionally, the preset threshold M is a positive integer, and M≥1. The value of M can be adjusted through the smart contract parameter configuration module.

[0028] Optionally, the smart contract also has a built-in permission management function, which supports dynamically updating the list of trusted assertors. The trusted assertors and their corresponding public keys can be added, deleted, or modified through the permission management function.

[0029] Optionally, it includes:

[0030] Contract Deployment Module: Used to deploy smart contracts to the blockchain network;

[0031] DID registration module: Used to receive the user's master public key, call the smart contract registration function to complete the creation and initial state setting of the decentralized identifier, and store the association between the decentralized identifier and the master public key;

[0032] State Management Module: Used to maintain the lifecycle state of DID, execute state transition operations according to the smart contract's preset rules, and trigger corresponding operations;

[0033] Assertion Validation Module: Used to perform full-process validity validation of binding assertions and count the number of binding assertions that pass the validation.

[0034] The technical solution of this invention has the following beneficial effects:

[0035] This invention employs a three-pronged architecture: smart contract control, multi-party assertion verification, and blockchain immutability. The identity state machine smart contract serves as the core control unit, managing the entire lifecycle of a DID through fixed state transition rules. Cross-verification by authoritative and trusted assertors forms the foundation of trust, while a threshold mechanism strengthens the security of identity binding and recovery. Blockchain provides the underlying support, ensuring the immutability and traceability of all operation records. In use, the smart contract achieves its function through the following process: the user creates a DID and completes initial registration → strong binding and full permissions are obtained through multi-party binding assertions → in case of private key loss, a recovery process is triggered using low-permission credentials, and key updates and state recovery are completed through secondary verification and recovery assertion verification → the user can proactively initiate identity revocation to terminate DID permissions. This design allows the smart contract to perform its functions without centralized intervention throughout the entire process. It retains the autonomous and controllable characteristics of decentralized identity while addressing the core pain points of existing technologies through multi-party authoritative endorsement and rigorous verification mechanisms, achieving a balance between security, credibility, and ease of use. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0037] Figure 1 This is a flowchart illustrating the steps involved in implementing the strong identity binding function in a decentralized identity strong binding and secure recovery method according to the present invention.

[0038] Figure 2 This is a flowchart illustrating the steps involved in implementing the secure recovery function in a decentralized identity strong binding and secure recovery method according to the present invention.

[0039] Figure 3 This is a flowchart illustrating the steps involved in implementing the identity revocation function in a decentralized identity strong binding and secure recovery method according to the present invention.

[0040] Figure 4 This is a flowchart illustrating the risk assessment process performed by the AI ​​risk perception engine in a decentralized identity strong binding and security recovery method according to the present invention.

[0041] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0042] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0043] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0044] Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0045] This invention proposes a decentralized identity strong binding and secure recovery method.

[0046] like Figure 1 As shown, in Embodiment 1 of the present invention, the decentralized identity strong binding and secure recovery method implements the identity strong binding function by specifically including the following steps:

[0047] S1: Deploy a smart contract on the blockchain network. This smart contract includes a registration function, a DID lifecycle set (i.e., a set of lifecycle states for decentralized identifiers), state transition rules, a list of trusted assertors, and assertion verification logic. The DID lifecycle set includes unverified, verified, recovering, and revoked states. Additionally, the assertor list includes authoritative institutions such as banks and telecommunications operators.

[0048] S2: Users generate a master-public-private key pair by calling the registration function of the smart contract (private key is stored securely locally), and submit the master-public key. Then, the smart contract assigns a unique decentralized identifier to the master-public key and sets the initial state of the decentralized identifier to an unverified state. At the same time, the association between the decentralized identifier and the master-public key is constructed and stored through a data structure (such as a mapping data structure), i.e., the "DID - identity information" association.

[0049] S3: For decentralized identifiers in an unverified state, the user first initiates a binding request to at least N (N≥M) of the aforementioned trusted assertors. After the assertors undergo offline or online KYC processes to strictly verify the user's physical identity, they issue a binding assertion with a digital signature. Then, the user collects M~N binding assertions and submits them to the smart contract. The smart contract performs a full-process validity verification on each binding assertion. When the number of verified binding assertions reaches a preset threshold M, the decentralized identifier is converted from an unverified state to a verified state, and full operational permissions are granted to the decentralized identifier.

[0050] Specifically, the above steps construct a cross-validation system by introducing multiple authoritative and trusted assertors, leveraging institutional credibility to strengthen the mapping relationship between decentralized identifiers (DIDs) and physical identities. Simultaneously, a preset threshold M for binding assertions ensures that high privileges are granted only after a sufficient number of independent assertors confirm the user's physical identity, mitigating the risk of a single assertor being compromised or misjudged. Furthermore, smart contracts solidify the state transition rules and verification logic of the decentralized identifiers (DIDs), ensuring that all operations require no human intervention, guaranteeing a transparent and tamper-proof process, thus achieving the automation function of smart contracts.

[0051] Furthermore, the above technical solution can achieve several beneficial effects:

[0052] 1. Significantly enhances the strength of user identity binding: Relying on the strict verification by authoritative assertors and the multi-assertion threshold mechanism, the identity binding relationship has anti-forgery and anti-cracking characteristics, which can meet the identity credibility requirements of high-security scenarios such as finance and government affairs.

[0053] 2. Trustless execution: By executing automated verification and state transition operations through smart contracts, the fairness and traceability of identity binding can be effectively guaranteed.

[0054] 3. Hierarchical permission control: Unverified decentralized identifiers only have basic permissions, while verified decentralized identifiers have higher-level permission operations, forming a secure closed loop of "verification-authorization".

[0055] like Figure 2As shown, in this invention, a decentralized identity strong binding and secure recovery method to achieve secure recovery functionality specifically includes the following steps:

[0056] S4: The aforementioned smart contract also includes a built-in recovery startup function. For a verified decentralized identifier, when a user's master private key is lost, the contract's recovery startup function can be invoked by initializing a preset low-privilege "Restore Device / Restore Private Key" function. Once the smart contract verifies the user's recovery permissions, it changes the decentralized identifier from a verified state to a recovery-in-progress state and initiates a high-risk operation freeze mechanism, thereby freezing high-risk operations such as transfers, permission changes, and asset staking.

[0057] S5: For decentralized identifiers in the recovery phase, the user first initiates a recovery request to at least J (J≥K) trusted assertors. After verifying the user's physical identity through more stringent secondary verification methods such as facial recognition and real-time video calls, the assertors issue a recovery assertion. Then, the user collects J~K recovery assertions and submits them to the smart contract. The smart contract performs a full-process validity verification consistent with the bound assertions (only the type verification is "recovery assertion"). When the number of verified recovery assertions reaches a preset threshold K, the master public key associated with the decentralized identifier is updated to the new public key, the decentralized identifier is changed from the recovery phase to the verified phase, and the high-risk operation freeze is lifted.

[0058] Specifically, the aforementioned secure recovery steps are initiated by preset low-privilege credentials, ensuring the security of the recovery entry point while avoiding recovery failure issues caused by reliance on the master private key. Furthermore, the recovery process freezes high-risk operations, effectively preventing asset loss; only when the user updates the master public key through the secure recovery steps, rendering the old private key completely invalid, is the decentralized identifier transitioned from the recovery state to the verified state, and the freeze on high-risk operations lifted, thus achieving a secure transfer of identity and assets.

[0059] Furthermore, the above technical solution can achieve several beneficial effects:

[0060] 1. Solve the pain point of lost private keys: Provide a decentralized and secure recovery path, so users do not need to rely on centralized custody or ordinary social contacts, completely avoiding the risk of permanent loss of identity and digital assets.

[0061] 2. The recovery process is safe and controllable: triple protection of secondary strong verification, threshold assertion verification, and high-risk operation freezing can effectively resist malicious behaviors such as collusion attacks and identity theft.

[0062] 3. Seamless Permissions: After recovery, the DID lifecycle and permissions are fully restored, the new public key is rebound to the decentralized identifier, and users can continue to use identity-related functions normally.

[0063] Furthermore, in step S4, the high-risk operation freeze mechanism includes prohibiting decentralized identifiers from performing transfers, permission changes, and asset staking operations. This design effectively isolates risks such as malicious transfers and asset misappropriation during the recovery process, providing a "safe window" for user identity restoration. Moreover, the freeze and unfreeze logic is entirely executed automatically by smart contracts, requiring no manual intervention, and users can clearly understand the correspondence between status and operational permissions.

[0064] like Figure 3 As shown, in this invention, a decentralized identity strong binding and secure recovery method further includes the following steps:

[0065] S6: The aforementioned smart contract also includes a built-in revocation function. When a user initiates an identity revocation request, the revocation function is called through the smart contract. After the smart contract verifies the legality of the request, the corresponding decentralized identifier is set to a revoked state, and all operational permissions for that decentralized identifier are terminated to ensure the seriousness of identity cancellation. The blockchain, through its immutable nature, ensures that the revocation record is auditable and traceable. Specifically, this design can meet users' identity cancellation needs, supports users actively relinquishing control of their identity, and adapts to cancellation scenarios arising from identity changes, privacy protection, and other needs. Simultaneously, all operational permissions are immediately terminated after the decentralized identifier is revoked, preventing the illegal abuse of the cancelled identity and ensuring user identity security.

[0066] Specifically, in step S1 above, the deployment process of the smart contract includes:

[0067] S11: Write smart contract code using a programming language (such as Solidity) that includes a registration function, a DID life state set, state transition rules, a list of trusted assertors, and assertion verification logic;

[0068] S12: Compile smart contract code into bytecode executable by the blockchain virtual machine;

[0069] S13: Bytecode is sent to the blockchain network by creating a transaction. After the blockchain nodes in the blockchain network execute the transaction, a contract account is created and the contract code is stored.

[0070] S14: Records the unique blockchain address corresponding to the contract account. Users and applications use this unique blockchain address to call contract functions.

[0071] The deployment process of the aforementioned smart contracts follows the EVM execution specification. By recording transactions on the blockchain, the smart contract code is permanently stored and consensus is achieved across the entire network. A unique blockchain address is used as the interaction entry point to ensure the uniqueness and accuracy of calls. This design permanently solidifies the code after it is recorded on the blockchain, preventing any entity from arbitrarily modifying the rules and ensuring the stability and security of the identity management process. Furthermore, the unique blockchain address supports cross-node calls from all users and applications, ensuring the decentralized access characteristics of the system.

[0072] Furthermore, in step S2 above, the smart contract constructs a "DID-identity information" mapping relationship through a data structure. The identity information includes the current life status of the DID, the associated public key, and the recovery configuration parameters, supporting quick querying and updating of the corresponding identity data through a decentralized identifier.

[0073] Furthermore, in step S3, the full-process validity verification of the binding assertion includes:

[0074] S31: Extract the issuer DID from the binding assertion, and query the corresponding public key in the smart contract's preset list of trusted assertors. If the key is not found, the verification fails.

[0075] S32: Remove the signature field from the binding assertion, reorganize the remaining fields in a preset order. The remaining fields include the issuer DID, the assertion object DID, the assertion content, and the assertion validity period, and calculate the hash value.

[0076] S33: Call the cryptographic verification function built into the blockchain virtual machine, input the hash value, the signature in the binding assertion, and the public key of the issuing party found, to verify the authenticity of the signature;

[0077] S34: Verify the consistency between the assertion object DID and the user DID of the current operation, whether the assertion validity period has expired, and whether the assertion type is a bound assertion. If all verifications pass, the bound assertion verification is valid.

[0078] Similarly, in step S5, the full-process validity verification of the recovery assertion is consistent with the verification process of the binding assertion described above, and the type verification of the recovery assertion is to confirm whether the assertion is a recovery assertion.

[0079] The aforementioned full-process validity verification of binding and recovery assertions only recognizes binding or recovery assertions issued by assertions listed in the assertion party list, excluding invalid credentials from organizations not on the list. Simultaneously, based on asymmetric encryption technology, public key verification of signatures ensures that assertions are genuinely issued by the issuing party and their content has not been tampered with. Therefore, this design forms a triple verification system of "trusted source - genuine signature - business compatibility," thereby preventing forged, expired, and mismatched invalid assertions. Furthermore, threshold statistics based solely on valid assertions ensure that verified decentralized identifiers possess genuine physical identity endorsement.

[0080] In this embodiment, the preset thresholds M and K are both positive integers, with M≥1 and K≥1. The values ​​of M and K can be adjusted through the smart contract parameter configuration module. This design allows users to flexibly adjust the specific values ​​of M and K according to the security requirements of the actual application scenario through the built-in parameter configuration module of the smart contract. This facilitates adaptation to scenarios with different security requirements. For example, a higher threshold (such as M=3, K=2) can be set to adapt to scenarios with high security requirements, such as finance, while the threshold can be appropriately lowered to simplify operations and adapt to ordinary life scenarios.

[0081] In this embodiment, the smart contract also includes a built-in permission management function that supports dynamically updating the trusted assertion list. This function allows for the addition, deletion, or modification of trusted assertions and their corresponding public keys. This design solidifies update permissions and processes through the smart contract, ensuring that only authorized entities can modify the trusted list. Furthermore, the blockchain records the update history, guaranteeing traceability. It also adapts to scenarios involving changes in assertion qualifications or the addition of authoritative institutions, helping to prevent system failures due to assertion changes.

[0082] Furthermore, the aforementioned smart contract also incorporates a built-in duplicate assertion interception mechanism. By recording the issuer DID of verified assertions, it prevents the same issuer from repeatedly submitting assertions for the same operation for the same DID. This design records verified assertions using a combination key of "issuer DID + user DID + operation type," ensuring that an assertion for the same operation by the same entity can only be effective once. This prevents users from "making up the numbers" by repeatedly submitting credentials from the same assertor, ensuring that thresholds M and K reflect the cross-validation results of multiple independent assertors.

[0083] like Figure 4 As shown, this invention also includes an AI risk perception engine. When a user performs identity binding or identity restoration operations, the AI ​​risk perception engine can analyze the actual situation to determine the risks and provide appropriate feedback based on the risk assessment results. For example, during identity binding, it can identify risks such as synthesized identities, identity theft, and bulk registration; during identity restoration, it can identify risks such as SIM card hijacking and social engineering attacks (phishing emails).

[0084] (Note: The risk score of the AI ​​risk perception engine below is just an example. It can be configured according to the scenario in practice.)

[0085] 1. In the aforementioned identity binding process, the user's decentralized identifier (DID) is initially in an unverified state. When a user submits an identity binding request, the AI ​​risk perception engine is triggered to analyze the actual situation and determine the risk. The following are the path differentiation processing operations performed by the AI ​​risk perception engine in the identity binding process based on the risk assessment results:

[0086] Low-risk path ([AI risk perception engine risk score < 30]): If the AI ​​risk perception engine assesses this as a routine, low-risk registration (e.g., the registration request originates from a trusted home network and exhibits no unusual behavior), the system will choose this "fast track." The smart contract only needs to verify a minimum number (M) of assertions for the user to quickly complete the binding process, transforming the decentralized identifier (DID) from an unverified state to a verified state.

[0087] High-risk path (AI risk perception engine risk score ≥ 30): If the AI ​​risk perception engine detects suspected fraudulent registration (e.g., registration request originating from a proxy IP, abnormal device fingerprint), the system will automatically switch to the "strict review channel." The smart contract will execute an enhanced verification strategy, requiring users to provide more or higher-weighted assertions (e.g., M+1). Only by meeting this higher threshold can a decentralized identifier (DID) transition from an unverified state to a verified state.

[0088] 2. In the aforementioned identity recovery process, the user's decentralized identifier (DID) is in a recovery in progress state. When a user submits an assertion for identity recovery, the AI ​​risk perception engine can be triggered to analyze the actual situation and determine the risk. The following are the path differentiation processing operations performed by the AI ​​risk perception engine in the identity recovery process based on the risk assessment results:

[0089] Low / Medium Risk Path ([AI Risk Perception Engine Risk Score < 70]): The AI ​​Risk Perception Engine assesses that the user is performing recovery in a relatively safe environment. The system will select the "Standard Recovery Channel," and after verifying K assertions, directly change the Decentralized Identifier (DID) from the RecoveryInProgress state to the Verified state, and reset a new key for it.

[0090] High-risk path (AI risk perception engine risk score ≥ 70): The AI ​​risk perception engine assessment indicates that this recovery request is highly likely an account theft attempt initiated by an attacker. The system will not directly restore the identity, but will instead redirect the request to a special "security isolation zone"—AdditionalVerification.

[0091] The Additional Verification state is a temporary "waiting and reviewing" state. The identity restoration process for decentralized identifiers (DIDs) that enter this state is suspended. The Additional Verification state can be lifted using the following steps:

[0092] Success path: Users must pass the highest level of verification (such as remote video or AI liveness detection). Only after successful verification can the Decentralized Identifier (DID) be converted to a verified state, completing the recovery process.

[0093] Failure path: If the user review fails or there is no response within the timeout period, the Decentralized Identifier (DID) will fall back to the RecoveryInProgress state, keeping the Decentralized Identifier (DID) account in a secure locked state, thereby preventing attackers from launching account theft attempts.

[0094] This invention also discloses a decentralized identity strong binding and secure recovery system for implementing the decentralized identity strong binding and secure recovery method described above, comprising:

[0095] Contract Deployment Module: Used to deploy smart contracts to the blockchain network to generate a unique blockchain address;

[0096] DID registration module: Used to receive the user's master public key, call the smart contract registration function to complete the creation and initial state setting of the decentralized identifier, and store the association between the decentralized identifier and the master public key;

[0097] State Management Module: Used to maintain the lifecycle state of DID (unverified, verified, in recovery, revoked), and to perform state transition operations according to the smart contract's preset rules, and trigger corresponding operations (such as granting permissions, freezing for high-risk operations).

[0098] Assertion Validation Module: Used to perform full-process validity validation of binding assertions and count the number of binding assertions that pass the validation.

[0099] Security recovery module: Used to respond to user recovery requests, initiate the recovery process, verify the validity of recovery assertions, complete public key updates and state restoration, and unfreeze high-risk operations;

[0100] Access control module: Used to manage the operation permissions of decentralized identifiers, granting or restricting corresponding functions based on the current state of the DID, and supporting identity revocation and updating of the trusted assertion list.

[0101] The decentralized identity strong binding and security recovery system is functionally divided into the modules mentioned above. Each module focuses on a specific core task and achieves end-to-end collaboration through interface interaction, adhering to the design principle of "high cohesion and low coupling." Therefore, it offers multiple beneficial effects:

[0102] 1. Clear and maintainable architecture: Modular design reduces system complexity and facilitates subsequent feature iterations and troubleshooting;

[0103] 2. Efficient and collaborative workflow: Each module automatically connects according to preset logic without manual intervention, ensuring the efficient execution of operations such as identity binding, restoration, and revocation;

[0104] 3. High scalability: Upgrading the functionality of a single module (such as adding assertion verification rules or expanding the list of high-risk operations) does not affect other modules, thus improving the system's adaptability.

[0105] The above description is merely a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural transformations made using the contents of the present invention's specification and drawings under the inventive concept of the present invention, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A decentralized identity strong binding and secure recovery method, characterized in that, Includes the following steps: S1: Deploy a smart contract on a blockchain network. The smart contract has a built-in registration function, a DID life state set, a state transition rule, a list of trusted assertors, and assertion verification logic. The DID life state set includes unverified state and verified state. S2: The user generates a master public key pair by calling the registration function of the smart contract. The smart contract assigns a unique decentralized identifier to the master public key and sets the initial state of the decentralized identifier to an unverified state, while storing the association between the decentralized identifier and the master public key. S3: For decentralized identifiers in an unverified state, when a user submits multiple binding assertions to the smart contract, the AI ​​risk perception engine scores the risk of the binding operation, and the smart contract performs full-process validity verification on each binding assertion. The low-risk path is when the AI ​​risk perception engine has a risk score of <30. When the number of verified binding assertions reaches a preset threshold M, the decentralized identifier will be converted from an unverified state to a verified state. The high-risk path is when the AI ​​risk perception engine has a risk score of ≥30. When the number of verified binding assertions reaches the preset threshold M+1, the decentralized identifier will be converted from an unverified state to a verified state. The AI ​​risk perception engine is used to identify risks such as synthetic identities, identity theft, and bulk registration. The full-process validity verification of the bound assertions in step S3 includes: S31: Extract the issuer DID from the binding assertion, and query the corresponding public key in the smart contract's preset list of trusted assertors. If the key is not found, the verification fails. S32: Remove the signature field from the binding assertion, reorganize the remaining fields in a preset order. The remaining fields include the issuer DID, the assertion object DID, the assertion content, and the assertion validity period, and calculate the hash value. S33: Call the cryptographic verification function built into the blockchain virtual machine, input the hash value, the signature in the binding assertion, and the public key of the issuing party obtained from the query, to verify the authenticity of the signature; S34: Verify the consistency between the assertion object DID and the user DID of the current operation, whether the assertion validity period has expired, and whether the assertion type is a bound assertion. If all verifications pass, the bound assertion verification is valid.

2. The decentralized identity strong binding and secure recovery method according to claim 1, characterized in that, It also includes the following steps: S4: The smart contract also has a built-in recovery startup function. The DID life state set also includes a recovery state. For the decentralized identifier in the verified state, when the user's master private key is lost, the smart contract's recovery startup function is called through a preset recovery method. After the smart contract verifies the user's recovery permission, it changes the decentralized identifier from the verified state to the recovery state and starts the high-risk operation freezing mechanism. S5: For a decentralized identifier in the recovery process, the user submits multiple recovery assertions to the smart contract. The smart contract performs full-process validity verification on each recovery assertion. When the number of verified recovery assertions reaches a preset threshold K, the master public key associated with the decentralized identifier is updated to a new public key, the decentralized identifier is changed from the recovery state to the verified state, and the high-risk operation freeze is lifted.

3. The decentralized identity strong binding and secure recovery method according to claim 2, characterized in that, In step S4, the high-risk operation freezing mechanism includes prohibiting decentralized identifiers from performing transfers, permission changes, and asset staking operations.

4. The decentralized identity strong binding and secure recovery method according to claim 1, characterized in that, It also includes the following steps: S6: The DID life state set also includes a revoked state. When a user initiates an identity revocation request, the smart contract sets the corresponding decentralized identifier to a revoked state and terminates all operation permissions of the decentralized identifier.

5. The decentralized identity strong binding and secure recovery method according to claim 1, characterized in that, The deployment process of the smart contract in step S1 includes: S11: Use a programming language to write smart contract code that includes a registration function, a DID life state set, state transition rules, a list of trusted assertors, and assertion verification logic; S12: Compile the smart contract code into bytecode executable by the blockchain virtual machine; S13: The bytecode is sent to the blockchain network by creating a transaction. After the blockchain node in the blockchain network executes the transaction, it creates a contract account and stores the contract code. S14: Record the unique blockchain address corresponding to the contract account. Users and applications can call contract functions through this unique blockchain address.

6. The decentralized identity strong binding and secure recovery method according to claim 1, characterized in that, In step S2, the smart contract constructs a "DID-identity information" mapping relationship through a data structure. The identity information includes the current life status of the DID, the associated public key, and the recovery configuration parameters.

7. The decentralized identity strong binding and secure recovery method according to claim 1, characterized in that, The preset threshold M is a positive integer, and M≥1. The value of M can be adjusted through the smart contract parameter configuration module.

8. The decentralized identity strong binding and secure recovery method according to claim 1, characterized in that, The smart contract also has a built-in permission management function, which allows for the addition, deletion, or modification of trusted assertors and their corresponding public keys.

9. A decentralized identity strong binding and secure recovery system, used to implement the decentralized identity strong binding and secure recovery method as described in any one of claims 1-8, characterized in that, include: Contract Deployment Module: Used to deploy smart contracts to the blockchain network; DID registration module: Used to receive the user's master public key, call the smart contract registration function to complete the creation and initial state setting of the decentralized identifier, and store the association between the decentralized identifier and the master public key; State Management Module: Used to maintain the lifecycle state of DID, execute state transition operations according to the smart contract's preset rules, and trigger corresponding operations; Assertion Validation Module: Used to perform full-process validity validation of binding assertions and count the number of binding assertions that pass the validation.

Images