General distributed digital identity authentication management method and system with high integration

Abstract

This invention proposes a highly integrated, general-purpose distributed digital identity authentication management method and system, comprising: a user providing initial KYC proof and encryption method for on-chain digital identity registration; after verification of the authentication information by an oracle, the user encrypts the private key using hashing and elliptic curve cryptography to generate a DID identifier field as an on-chain address and sends an identity registration request to the chain management node; the chain management node verifies the legality of the identity registration request; if the verification fails, it returns a registration failure result; if the verification succeeds, it generates a globally unique DID identifier based on the DID project name and chain ID of the identity chain and returns it to the user, while simultaneously creating an on-chain user address for the digital identity; the chain management node packages the user's authentication method and public key array information into a DID document and sends it to the user address in the form of a transaction for persistent storage on the chain.

Description

Technical Field

[0001] This invention relates to the field of blockchain and digital identity management technology, and in particular to a highly integrated universal distributed digital identity authentication method and system based on the fusion of blockchain and distributed digital identity. Background Technology

[0002] DID (Distributed Digital Identity) is a type of digital identity designed to achieve truly decentralized identities that users own and control entirely. Digital identities can be categorized into four types based on their development history: centralized identities, federated identities, user-centric identities, and distributed digital identities. Centralized identities, with their "multiple applications, multiple identities" approach, lead to password hurdles and excessive data sharing. Federated identities, on the other hand, rely too heavily on centralized institutions. User-centric identities were proposed to address these issues, but their reliance on single-carrier systems and traditional identity systems prevented widespread adoption. Distributed digital identities, however, grant users the ability to register a globally unique identity identifier without relying on any third-party platform, and all service providers and message recipients can verify the legitimacy and correctness of their identity. Users can also apply to a certificate issuing organization to store their identity authentication information locally, binding their identity information to this identifier, and autonomously controlling and displaying requested services, truly achieving absolute control over their own identity.

[0003] Distributed digital identity leverages the technological advantages of blockchain, managing and maintaining the identity system without relying on any single operator. Instead, it achieves decentralization, transparency, traceability, and tamper-proofing through multi-node consensus. Through digital signatures and encryption technology, it enables self-control of digital identity, allowing users to manage and control their own digital identities and selectively present verifiable identity information as needed. Furthermore, the W3C (World Wide Web Consortium) standard DID protocol enables interoperability of digital identities across different platforms and systems, facilitating the use of a unified, interoperable digital identity across various platforms.

[0004] Currently, the development of distributed digital identity is in its early stages, with some related projects and applications underway, but many technical and implementation challenges remain. Numerous blockchain projects, such as Ethereum, Hyperledger Indy, and Sovrin, are developing decentralized applications and protocols for identity management and verification. Government agencies in some countries are exploring the use of distributed digital identity technology to improve the security and efficiency of citizen authentication. Some organizations are developing open distributed digital identity standards, such as the W3C's Decentralized Identity Specification and the Verifiable Credentials (VC) data model, to promote the development and interoperability of distributed digital identity.

[0005] However, distributed digital identity technology is relatively new and its implementation is complex. Different technical solutions differ, making it difficult for ordinary users to understand and apply. Furthermore, distributed digital identity involves the storage and transmission of sensitive personal information, requiring strict adherence to on-chain data persistence and resource access control. Interoperability is also lacking between the different digital identity solutions mentioned above. These factors contribute to the low adoption and widespread use of distributed digital identity solutions. Therefore, given the aforementioned technological limitations, there is an urgent need to propose an efficient, convenient, reliable, and scalable distributed digital identity solution to advance the development of digital identity and the implementation of related technologies.

[0006] Existing distributed digital identities primarily employ blockchain and cryptographic technologies. However, current project implementations suggest that relying solely on these two technologies is insufficient to advance the development and widespread adoption of digital identities. While they can ensure the functionality of distributed digital identity application systems, numerous issues remain regarding compatibility, interoperability, and user acceptance.

[0007] like Figure 1 As shown, the infrastructure of distributed digital identity includes: DID identifiers, DID documents, and VCs. A DID identifier is a globally unique string in a specific format used to represent an entity's digital identity. Each DID identifier corresponds to a JSON string DID document, which contains the public key, authentication method, authorization information, server endpoint, and document-related information, using asymmetric encryption technology to implement the authentication method. A VC is a descriptive statement issued by one DID to endorse certain attributes of another DID, attached with its own digital signature, to prove the authenticity of these attributes; it can be considered a digital certificate. It contains VC metadata, statement content, and signature information. VCs are managed and controlled autonomously by users, stored off-chain, ensuring that identity data is always under the control of the end user. Personal identity information is not stored on the blockchain; only the hash value of the signature is used as evidence, making the user the sole owner of the identity, thus freeing them from the control of any centralized registration service, identity provider, or certificate authority. The distributed digital identity system is based on blockchain, realizing on-chain identity anchoring for entities. Leveraging the immutability and shared data access characteristics of blockchain, it achieves global uniqueness, readable availability, secure storage of identities, and traceable full lifecycle management. Based on DPKI (Distributed Public Key Infrastructure), authentication-related data is stored on the blockchain, and the authentication process does not depend on the application providing the identity or any other facility.

[0008] In a distributed digital identity system, the primary function of blockchain technology is to serve as a distributed database for storing identity verification methods and endorsing identity authentication information. Its most significant characteristic is decentralization; there is no centralized control institution, and the storage and exchange of data and information are achieved through mutual verification and synchronization between nodes. The DID system design technically guarantees decentralized storage of user identities. However, using a blockchain system means that every piece of data is also transparent and publicly available to all nodes. This characteristic means that a user's VC (Verification Document) can only exist off-chain; only a digest of the VC's correctness proof is stored on-chain. Therefore, users need to store multiple copies of their identity documents themselves or rely on third-party institutions for custody, which is a very user-unfriendly solution. Furthermore, the inconsistent VC format leads to difficulties in identity verification adaptation across different DID systems, and some projects, because VCs are not stored on-chain, do not specify a VC format.

[0009] DPKI is an implementation of Public Key Infrastructure (PKI). PKI is an infrastructure used to ensure the security of network communications. It uses digital certificates and public key encryption technology to achieve data encryption, authentication, and integrity protection. DPKI distributes PKI, replacing the traditional centralized management by CAs (Certificate Authorities) with distributed management. It uses distributed ledger technologies such as blockchain to make certificate management and verification processes more secure and reliable, while also better achieving decentralization, autonomy, and transparency. While DPKI technology is well-suited for distributed digital identity, it introduces new challenges. In terms of scalability, DPKI needs to meet high scalability requirements because it needs to support large-scale certificate issuance and verification operations. When facing large-scale networks and complex application scenarios, DPKI may encounter performance bottlenecks and topology complexity issues. Regarding access control, the traditional centralized CA model solves this problem well, but in distributed systems, effectively managing power and permissions, and preventing malicious behavior and attacks while effectively managing resources, presents a challenge.

[0010] Therefore, existing distributed digital identity schemes have many technical problems and shortcomings, making them unsuitable for immediate deployment in production and daily life. This is also why the adoption rate of distributed digital identities remains low. Summary of the Invention

[0011] To address the aforementioned technical problems, this invention proposes a highly integrated, universally distributed digital identity authentication management method, in which users and organizations complete digital identity registration, verification, and chain address creation on-chain, specifically including:

[0012] Step 1: The user provides initial KYC proof and encryption method to register an on-chain digital identity. After the oracle verifies the authentication information, the private key is encrypted using hash and elliptic curve cryptography to generate a DID identifier field as an on-chain address, and an identity registration request is sent to the chain management node.

[0013] Step 2: The chain management node verifies the legality of the identity registration request. If the verification fails, a registration failure result is returned. If the verification passes, a globally unique DID identifier is generated based on the DID project name and chain ID of the identity chain and returned to the user. At the same time, an on-chain user address is created for the digital identity.

[0014] Step 3: The chain management node packages the user's authentication method and public key array information into a DID document and sends it to the user's address in the form of a transaction for persistent storage on the chain.

[0015] Step 4: The organization sends registration data to the oracle, along with its identity certificate and a list of administrators; the chain management node verifies the organization's identity on the chain, generates a DID document for the organization, and saves the organization's administrator identity.

[0016] Step 5: The organization applies to the SCT registration module on the client side for VC declaration types that conform to its own business logic, and registers the data structure and verification method to the VC integration module;

[0017] Step 6: Organize a signed VC bulk registration notification broadcast to users and send your on-chain digital identity address to the original system users for user verification;

[0018] Step 7: Users provide digital identity and KYC verification information to the organization for secondary KYC verification, linking and binding the user's off-chain identity, on-chain identity, and organization VC declaration;

[0019] Step 8: The organization will use the VC integration module to uniformly generate VCs for all DID solutions to be interoperable, based on the user certificate information that has been reviewed and approved for integration, and return them to the user for storage off-chain.

[0020] Step 9: The organization verifies the batch data after VC integration through an oracle, outputs a VC digest, and sends it to the account address of the VC user, storing it on the chain and associating it with the user.

[0021] The aforementioned highly integrated general-purpose distributed digital identity authentication management method manages and maintains on-chain resources, including user DIDs, DID documents, VC proofs, and organizational hierarchy trees. The process is divided into DID management and VC management according to corresponding resource access control permissions. Specifically, DID management includes:

[0022] Step 10: The user submits a DID modification request to the on-chain management node;

[0023] Step 11: The on-chain management node calls the authentication contract, passing the user's DID identifier and identity credentials into the contract;

[0024] Step 12: The authentication contract calls the oracle contract. The oracle contract assigns an event ID to each call and executes it after signing, waiting for the oracle to listen.

[0025] Step 13: The oracle listens for on-chain events and matches and verifies them based on the data generated by consensus. If it fails, it retrieves data from the outside again and reaches consensus.

[0026] Step 14: The message verified by the oracle is transmitted to the chain. The administrator node reviews the legality of the application and returns the data type required by the interface to the user.

[0027] Step 15: The user uploads the new public key or new digital identity address to the chain. After consensus by the administrator node, the corresponding DID document is modified or a new chain address is added.

[0028] This VC management specifically includes:

[0029] Step 16: The user applies for VC off-chain from the organization, and after KYC verification, it is stored locally and the VC summary is sent to the user's account address and stored on the chain.

[0030] Step 17: When a user VC expires or is changed, the issuing organization updates the content and validity status of the user VC off-chain.

[0031] Step 18: Upload the updated VC to the blockchain using an encryption algorithm and send it to the user address to store the proof digest;

[0032] Step 19: When an organization fails, the superior organization manager accesses the organization's mounting management contract, deletes the node address in the chain's hierarchical tree, and mounts the child nodes onto this node to maintain the hierarchical relationship.

[0033] Step 20: The VC issued by the invalid organization is modified to the digital identity address of the superior organization according to the organization's mounting contract, and the corresponding verification method and service node in the VC are updated to achieve redirection.

[0034] Step 21: Send the updated VC to the user via the oracle contract. Store the updated VC locally and store the proof digest on the chain.

[0035] The highly integrated general-purpose distributed digital identity authentication management method, wherein step 1 includes:

[0036] When a user registers on the client, after verifying their mobile phone number, they enter the KYC authentication stage. The user provides identity information IDi and biometric information IDp. After collecting the biometric information, the client forwards the authentication request to the oracle. The oracle uses IDi to look up and verify the user's offline identity and returns the result to the client, thus achieving off-chain identity anchoring. After receiving the successful return result, the client notifies the user to set a key. The user selects encryption method M1, and the client calls the corresponding asymmetric cryptography generator to generate a distributed digital identity DID_URL and DID document based on the generated public key PA and the encryption method M1 selected by the user. The private key dA is returned to the user and stored locally. After obtaining the DID_URL, the client delivers the user's identity identifier and identity document to the oracle for trusted data verification. After successful verification, the data is uploaded to the blockchain, where the audit contract performs a uniqueness check on the identity identifier. After the check passes, the DID_URL and DIDDOC are associated and stored on the blockchain, and the successful audit result is returned to the user, thus achieving on-chain identity anchoring.

[0037] The highly integrated, general-purpose distributed digital identity authentication management method, wherein the KYC authentication method in step 1 includes:

[0038] After the client collects the user's identity information, it delivers it to the oracle. The oracle queries the user's biometric information from a trusted source and performs a match based on the user's identity. If the match is successful, the KYC authentication information is hashed, encrypted, and stored in the oracle's database. After the user obtains the DID_URL by setting a key, the client delivers it to the oracle for key-value association and storage to facilitate KYC authentication.

[0039] The methods for secondary KYC verification in step 7 include:

[0040] Users sign their VC registration requests using a distributed digital identity (DID_URL) and upload their KYC information and MP (Master Authentication Program) identity verification information for the Certificate Authority (CA). Upon receiving the VC registration request, the client calls the identity resolution contract on the DID chain to access the DID DOC and verify the signature's correctness. After successful verification, the client delivers the collected user information to the CA. The CA first verifies the user's digital identity based on the MP and simultaneously accesses an oracle to perform simple authentication of the user's ID, completing a trusted binding between the original digital identity system and the user's offline identity. After successful binding, a local database match is performed, and a VC is generated and signed using migration tools and returned to the user. Finally, before the VC credential is uploaded to the chain, the oracle verifies the authenticity of the VC signature. Upon successful verification, the VC is hashed and encrypted, and then the on-chain contract is invoked to associate and store the DID identifier and the VC.

[0041] The highly integrated general-purpose distributed digital identity authentication management method, wherein step 6 includes:

[0042] After generating a VC template that conforms to its business logic through SCT registration, the Certificate Authority (CA) waits for VC registration requests initiated by DID client users. Once the number of user registration requests reaches the threshold Txs, the CA queries the original system identity Uid of the batch-registered users based on the identity proof MP provided by the user and accesses the VC batch registration application. Using the certificate holder DID and the user information Uidi from the original system as parameters, the CA accesses the statement object returned by the database management tool. Through SQL statements and key-value queries associated with the Uidi, the CA obtains the data value Inf that needs to be migrated. Finally, the CA imports the corresponding Uid value into the VC in batches using the VC template's Key, completing the VC batch registration.

[0043] The highly integrated general distributed digital identity authentication management method includes an oracle used to collect and verify user offline identity data from an off-chain trusted user identity query system, ensuring the consistency between the user's offline identity and on-chain distributed digital identity before the user possesses a distributed digital identity.

[0044] The oracle is divided into on-chain and off-chain components: the on-chain component includes the oracle smart contract and the authentication smart contract, while the off-chain component consists of the oracle node pool and cluster database. Upon receiving an authentication request, the oracle checks the data packet content; if no DID identifier is found, it performs KYC standard verification. After the oracle retrieves data from the external database, consensus is reached before storage. The consensus process utilizes a threshold signature algorithm: Si is the shard signature for each consensus node, obtained by multiplying the node's private key pki, the aggregate public key P, and the member key Mki on an elliptic curve; the aggregate public key is obtained by non-linearly adding the public keys; the member key Mki is obtained by encrypting each node's identifier using its private key, proving that it is part of that consensus node. Before termination, it is necessary to verify how many nodes signed the message. If the number of nodes is less than the threshold or the number of identical messages is less than the threshold, consensus fails, and data needs to be retrieved from the external database again. If consensus is successful, KYC standard verification begins, and the result is returned to the client. At the same time, the information is stored in the local database for KYC verification. When a DID identifier on the chain needs to modify the business and obtain the off-chain identity of the transaction initiator, the identity verification contract sends a call request to the oracle contract. The oracle contract assigns an event ID to each call and executes it after signing, waiting for the oracle to listen. After the oracle listens for the event, it performs KYC verification. If it fails, it retrieves data from the external database again, updates the local user data Idp, matches it again, and returns the event verification result.

[0045] The highly integrated general distributed digital identity authentication management method includes step 4, which involves attaching the endorsement signature of the superior organization to the materials provided by the client to the oracle, and attaching the organization's identity to the parent node through an organization mounting contract.

[0046] This invention also proposes a highly integrated, general-purpose distributed digital identity authentication management system, in which users and organizations complete digital identity registration, verification, and chain address creation on the blockchain, specifically including:

[0047] Module 1: Users provide initial KYC proof and encryption methods to register their digital identity on the chain. After the oracle verifies the authentication information, the private key is encrypted using hash and elliptic curve cryptography to generate a DID identifier field as the on-chain address, and an identity registration request is sent to the chain management node.

[0048] Module 2: The chain management node verifies the legality of the identity registration request. If the verification fails, it returns a registration failure result. If the verification passes, it generates a globally unique DID identifier based on the DID project name and chain ID of the identity chain and returns it to the user. At the same time, it creates an on-chain user address for the digital identity.

[0049] Module 3: The chain management node packages the user's authentication method and public key array information into a DID document and sends it to the user's address in the form of a transaction for persistent storage on the chain.

[0050] Module 4: The organization sends registration data to the oracle, along with its identity certificate and a list of administrators; the chain management node verifies the organization's identity on the chain, generates a DID document for the organization, and saves the organization's administrator identity.

[0051] Module 5: The organization applies to the SCT registration module on the client side for VC declaration types that conform to its own business logic, and registers the data structure and validation method to the VC integration module;

[0052] Module 6: Organize a signed VC bulk registration notification broadcast to users and send its own on-chain digital identity address to the original system users for user verification;

[0053] Module 7: Users provide digital identity and KYC authentication information to the organization for secondary KYC authentication, linking and binding the user's off-chain identity, on-chain identity, and organization VC declaration;

[0054] Module 8: The organization will use the VC integration module to uniformly generate VCs that are interoperable across all DID solutions, based on the user certificate information that has been reviewed and approved for integration, and return them to the user for storage off-chain.

[0055] Module 9: The organization verifies the batch data after VC integration through an oracle, outputs a VC digest, and sends it to the account address of the VC user, storing it on the chain and associating it with the user.

[0056] The present invention also proposes a storage medium for storing a program that executes any of the highly integrated general-purpose distributed digital identity authentication management methods.

[0057] The present invention also proposes a client for the aforementioned highly integrated general-purpose distributed digital identity authentication management system.

[0058] As can be seen from the above solutions, the advantages of the present invention are:

[0059] With the rapid development of the digital economy, the issue of digital identity has become increasingly prominent, and distributed digital identity has received more and more attention and application. Since 2017, major technology companies and organizations at home and abroad have been actively exploring and promoting the development of distributed digital identity, launching their own technical solutions. However, no specific solution has yet achieved widespread adoption and application. Many problems exist in the practical implementation of this technology. This invention, through thorough research on existing technical solutions, summarizes and abstracts business logic and expands the infrastructure based on this. The technical effects are evident from several perspectives: for users, the system is more convenient to use and ensures the uniqueness of the user's digital identity; for organizations within traditional digital identity systems, integration is more convenient and better suited to actual production and daily life; for the specific identity chain, it not only standardizes the format but also implements access control logic at the contract level and achieves a trusted transmission method from off-chain data to on-chain data. Attached Figure Description

[0060] Figure 1 A diagram of a distributed digital identity system;

[0061] Figure 2 This is a diagram of the overall system architecture.

[0062] Figure 3 A diagram illustrating the methods for generating identities on the DID chain;

[0063] Figure 4 Flowchart for DID user registration;

[0064] Figure 5 This is a flowchart of the initial KYC verification process;

[0065] Figure 6 This is a flowchart of the secondary KYC verification process;

[0066] Figure 7 Layered interface diagram for data migration tools;

[0067] Figure 8Flowchart for VC batch issuance;

[0068] Figure 9 A flowchart of the decentralized oracle workflow;

[0069] Figure 10 This is the overall flowchart. Detailed Implementation

[0070] To achieve the above-mentioned technical effects, the present invention mainly includes the following key technical points:

[0071] Key Point 1: Utilizing a dual KYC authentication scheme to achieve off-chain entity anchoring for distributed digital identities. Technical Effects: Distributed digital identities require a one-to-one anchoring between the user entity and the on-chain DID identifier. Under this premise, a user-controlled digital identity system is achieved, including the verification method DID document and associated identity authentication VC. In the field of digital identity, to prevent internet crime, users need to undergo KYC authentication when registering their on-chain DID identifiers, and the user's KYC and on-chain address information are associated and stored off-chain, providing a basis for the management and operation of DID identifiers. Simultaneously, originating in the financial sector, many service providers now require users to undergo KYC authentication during registration. When service providers act as agents to import user verifiable claims in bulk, they require users to provide KYC authentication information and on-chain identity addresses, achieving correct association between VC and DID identifiers, and completing the user's on-chain identity authentication.

[0072] Key Point 2: Optimize user registration and authentication logic using off-chain client VC integration plugins. Technical Effects: Different CA issuing organizations use different data structures for claims in their custom VCs according to business scenarios. However, all claim structures need to be registered with the SCT module to ensure network uniqueness and consistency with VC verification logic. Utilizing a VC aggregator, organizations such as certificate issuers and service providers act as agents for users to complete VC binding and notarization, lowering the application threshold for users and optimizing the registration process. Furthermore, the issued certificates are bound to the on-chain identities of certificate holders, and on-chain proofs are generated through encryption.

[0073] Key Point 3: Adding an identity-based resource access control mechanism to the existing on-chain logic of distributed digital identity solutions. Technical Effect: The DID identity chain is also a type of blockchain, possessing decentralized, transparent, and immutable characteristics. To achieve identity management in a decentralized system, the inventors introduced the RBAC model to classify on-chain resources (including DID identifiers, DID documents, and VC proofs) and on-chain identities (including ordinary users, organizations, organization administrators, and identity chain administrators). Through consensus, on-chain addresses and nodes are associated with on-chain identities, enabling identity-based access and operation control of classified resources. This improves the scalability of the management model without affecting the underlying chain structure, achieving the management and maintenance of on-chain identity data.

[0074] Key Point 4: Based on the existing hierarchical CA strategy for digital identity, introduce an organizational hierarchical endorsement mechanism. Technical Effects: In real-world production and life, not only are CA issuing institutions hierarchical, but there are also supervisory and management departments. For digital identity, if there is no hierarchical relationship between organizational identities on the chain, then once the organization fails, user identity data will become an "island" on the chain, unmodifiable and inaccessible, and persistently stored on the identity chain. At the same time, the flat on-chain logic will prevent the off-chain hierarchical organizational relationships from being reflected in the distributed digital identity system. The hierarchical endorsement mechanism generates an organizational relationship tree. Through the endorsement signature provided during organization registration, the identity management permissions and authentication VC information of the organization to be registered can be synchronously inherited to the parent node, improving system robustness.

[0075] Key Point 5: Utilizing decentralized oracle technology to provide a secure environment for interaction between the identity chain and off-chain entities. Technical Effects: Existing technical solutions do not solve the on-chain consensus problem for off-chain identity information. However, to bind on-chain digital identities to off-chain entities, a trusted environment must be provided for external data received on-chain. Since smart contracts cannot actively acquire off-chain data, but can only passively receive it, decentralized oracle technology can open up a pathway for interaction between the identity chain and the outside world. Off-chain, multiple nodes are deployed to find various information sources to ensure data availability and trustworthiness; threshold signatures ensure consistent consensus and trustworthiness of on-chain data; and a hardware-based security environment provides a secure environment for oracle nodes, mitigating the risk of identity data attacks and theft.

[0076] While researching distributed digital identity, the inventors discovered that existing blockchain and DPKI systems can achieve the basic functions of DID, but they have problems with integration and interoperability. Current solutions have not yet delved into the scalability of DID, with the main challenges including the following:

[0077] (1) Inconsistent data formats lead to redundant authentication logic: The Verifiable Claims (VC) data specification in the Distributed Digital Identity Standard contains many optional fields, and essential fields such as claim content and claim type are not specifically required, only functional descriptions are provided. Therefore, the verifiable claim formats in current solutions are inconsistent. If different service providers adopt different DID projects to implement distributed digital identity, they will face the problem of inconsistent VC formats. For example, the verifiable claim data organization formats of Serto on Ethereum and Weidentity on WeBank are very different. This will cause the verification entity to adapt to multiple different verification methods when performing authentication, which increases the deployment cost of the application and the complexity of the verification logic.

[0078] (2) Lack of access control mechanisms for on-chain resources leads to difficulties in identity management: The underlying technology supporting distributed digital identity is blockchain, which uses a consensus mechanism to ensure data consistency and credibility. Through the consensus mechanism, multiple nodes can reach a consensus, ensuring the correctness and consistency of data in the network. Moreover, with the support of the consensus mechanism, data on the blockchain is persistently stored, and all nodes can verify and confirm the validity and integrity of the data, realizing data traceability. However, this also means that all nodes (or all nodes in an organization for a consortium blockchain) can access the underlying data stored on the blockchain. Furthermore, due to the immutability of the blockchain, if there are vulnerabilities in the on-chain smart contracts, it will pose a serious threat to user data security. Therefore, the on-chain and off-chain user data storage methods and synchronous verification endorsement strategies need to be designed with security in mind, considering both security and functional completeness, while also taking into account system performance, making trade-offs in the "trilemma" scenario. In addition, on-chain functions should be as simple as possible, dedicated to distributed digital identity, reducing the risk of contract vulnerabilities and increasing the throughput of identity management transactions. As an on-chain application system, distributed digital identity, while possessing decentralized storage characteristics, cannot lack management mechanisms. It requires the management of on-chain resources such as DID identifiers, DID documents, and verifiable claims. However, current technical solutions have not abstracted these on-chain resources into an identity and access control model, creating potential risks for future application maintenance and management.

[0079] (3) Inability to guarantee the uniqueness of digital identities: While DID solutions stipulate the global uniqueness of DID identifiers, they do not require the uniqueness of on-chain identities for entities. Therefore, one-to-many and many-to-one relationships between entities and on-chain identities can exist. If a user authenticates and authorizes multiple digital identities, the system cannot verify the authenticity and validity of those identities, thus reducing the system's credibility and stability, and creating difficulties in tracing digital economic crimes and other areas. Furthermore, if multiple users use the same digital identity for authentication and authorization, it can lead to security issues such as identity theft and information leakage.

[0080] (4) System Integration Difficulties: Distributed digital identity requires compatibility and integration with existing centralized and consortium identities, and may even require frequent interoperability with existing systems in the early stages of implementation. Existing technical solutions involve on-chain identity registration and authentication on a user-by-user basis, but a user may have multiple identities across multiple service providers and institutions, which increases the time complexity of integration. Furthermore, the convenience of centralized identities makes many user identities transparent during use, and multiple intermittent identity registrations by a single user result in low system migration efficiency. In addition, distributed digital identity systems are more complex than traditional identity verification methods and may require considerable time and resources for promotion and popularization. This places higher demands on user operation and necessitates careful consideration of acceptance and technical training issues.

[0081] To make the above features and effects of the present invention clearer and easier to understand, specific embodiments are described below, and detailed descriptions are provided in conjunction with the accompanying drawings.

[0082] To address the aforementioned issues, this invention extends existing distributed digital identity solutions. For traditional digital identity schemes, it utilizes technologies such as oracles and KYC authentication to achieve trusted on-chain registration and efficient integration of user and organizational identities. For on-chain application logic, it implements access control for on-chain resources based on the RBAC (Role-Based Access Control) model and permission tree, maximizing system compatibility without interfering with on-chain logic. This suite enables a convenient and universal distributed digital identity system. The specific system architecture is as follows: Figure 2 As shown.

[0083] Client:

[0084] The client consists of four parts: DID registration module, KYC two-factor authentication, VC integration module, and SCT standard.

[0085] (1) As Figure 3 As shown, after a user entity completes off-chain identity authentication, a key pair is generated using either the Elliptic Curve Digital Signature Algorithm (ECDSA) or the SM2 and SM3 national cryptographic algorithms, based on the key generation algorithm selected by the user. After key generation, the user's private key needs to be securely stored locally to prevent leakage or loss. The public key, as the last field of the DID identifier, is combined with the project name and chain ID of the corresponding identity chain to generate the off-chain user's on-chain digital identity ID.

[0086] (2) KYC (Know Your Customer) dual authentication is responsible for uniquely anchoring the on-chain identity of off-chain entities. KYC authentication is a professional term in the financial field. For financial security, users need to provide identity verification. In the field of digital identity, it is also necessary to prevent internet crime, so KYC authentication is required when users register their on-chain DID identifiers. The first KYC authentication occurs before the user registers their on-chain digital identity, associating the user's KYC authentication result with the on-chain address information and storing it off-chain, providing a basis for the management and operation of DID identifiers. The second KYC authentication occurs when an organization issues VC to a user, binding the on-chain address of the VC recipient with the off-chain entity identity to prevent the theft or sale of VC authentication information. Through dual KYC authentication, the identity authentication relationship of entities in real life is accurately mapped to the on-chain, ensuring the uniqueness and correctness of the user's digital identity.

[0087] (3) The VC integration module is designed for traditional centralized and federated identities, enabling the batch integration of identity information from historical systems. Through on-chain event subscriptions, once a certain number of newly registered digital identities are reached, a batch VC import confirmation is triggered on an organization-by-organization client. After collecting the on-chain address and KYC authentication information of the certificate recipients, the organization creates a suitable VC type and parsing method according to the VC declaration format and accesses the database. Using a JDBC-based data migration tool, the original digital identity information is extracted and a verifiable declaration is generated according to the VC format. New certificates are then issued to users and associated with on-chain addresses for verification. This simplifies the user logic and lowers the barrier to entry for distributed digital identities, contributing to the development and popularization of new digital identity systems.

[0088] (4) The purpose of SCT (Standard Claim Type) is to generate a standardized, parsable format for existing VCs in different formats according to the organization's business needs. It is a standard methodology suite for VC registration and parsing. Except for the Claim field, all other fields are mandatory and participate in the VC verification process. The Claim field is defined by the Certificate Authority, does not participate in VC verification, and can be selectively disclosed when presented by the user. The standard format is shown in the table below:

[0089]

[0090] Table 1 VC Standard Format

[0091] Identity Chain:

[0092] The Identity Chain system suite consists of five parts: a decentralized oracle, an organization mounting contract, a DID audit module, an identity verification module, and an access control module.

[0093] (1) Blockchain is a network based on internal node consensus. Its data source is only on-chain nodes, and the program execution logic is encapsulated in contracts and runs on a deterministic virtual machine. Its consensus mechanism and deterministic virtual machine mean that the blockchain cannot obtain off-chain data. However, decentralized oracles can be used to provide a trusted off-chain source for identity data that needs to be stored on-chain. For DID identifiers and DID documents, multiple nodes collect consistent registration information and KYC authentication information off-chain. After verification, the registration request is uploaded to the chain. For VC proofs, the issuer's signature and the user's identity must be correct before the VC proof information can be uploaded to the chain and bound to the user entity. Off-chain users and organizations verify their identity and permissions before accessing on-chain resources. The verification process uses threshold signatures of decentralized nodes to confirm the identity of users on the chain through consensus, and multiple nodes collect information from multiple parties on the service node to ensure the timeliness and authenticity of messages. The entire process is carried out in a secure hardware environment.

[0094] (2) The DID verification module performs a uniqueness check on the DID identifiers generated by the client for off-chain entities. If the DID identifier field already exists, the registration application is rejected. If the verification is successful, a chain address is created and bound to the DID document. In the system design of this invention, the identifier field of the DID is the on-chain address. Since the DID method field of different chains in different projects will never be repeated, uniqueness verification can be achieved using chain address validity verification. This simplifies the traditional DID identifier verification logic.

[0095] (3) The authentication module has two functions. First, it associates and stores the off-chain VC proof. Second, it uses the DID identifier and the corresponding DID document parsing method to check the correctness of the signature information or VC path transmitted from off-chain, and returns the result to the off-chain caller.

[0096] (4) The function of the access control module is to classify the resources stored on the chain, specify the operation permissions of different identities for each resource, associate the members on the chain with identities, and implement an identity control scheme that is decoupled from the underlying logic of the chain, referring to the RBAC-1 model.

[0097] (5) The function of the organization's mounting contract is to map the organization's off-chain hierarchical relationships to the on-chain. The organization's chain address format is different from that of ordinary users, and mounting options are provided to the organization during digital identity registration. By providing upper-level signature endorsement, the organization manager's VC operation permissions within its jurisdiction can be inherited to the upper-level on-chain organization administrator. By maintaining the organizational hierarchy tree, the scope of VC administrators is expanded, preventing the loss of user VC management due to organizational failure and the formation of gray areas in on-chain management.

[0098] The purpose of this invention is to address the issues of backward compatibility, efficient integration, and scalability in existing distributed digital identity systems. Utilizing technologies such as database migration and oracles, and theoretical models like RBAC, this invention abstracts on-chain transaction logic and extends the system architecture based on blockchain and cryptographic infrastructure, designing a secure, controllable, user-friendly, and interoperable distributed digital identity suite. The main functional modules include a DID registration module, a dual KYC authentication module, a VC batch registration module, a decentralized oracle module, and an access control module. The detailed design of each module is as follows:

[0099] DID registration module:

[0100] like Figure 4 As shown, when a user registers on the client, the authenticity of their mobile phone number is verified using a dynamic password sent via SMS. After completing the mobile phone number verification, the user enters the KYC authentication stage. The user provides identity information IDi (ID card number, mobile phone number) and biometric information IDp (such as dynamic facial recognition, fingerprint, etc.). After the client collects the biometric information, it forwards the authentication request to an off-chain oracle. The oracle uses IDi to look up and verify the user's offline identity. Upon successful verification, it returns the result to the client, thus achieving off-chain identity anchoring. After receiving the successful return result, the client notifies the user to set a key. The user selects encryption method M1. The client calls the corresponding asymmetric cryptography generator and generates a distributed digital identity DID_URL and DID document based on the generated public key PA and the encryption method M1 selected by the user. The private key dA is then returned to the user and stored locally. After obtaining the DID_URL, the client delivers the user's identity identifier and identity document to the oracle for trusted data verification. Once verified, the data is uploaded to the blockchain, where an audit contract checks the uniqueness of the identity identifier. If the check passes, the DID_URL and DIDDOC are associated and stored on the blockchain, and the successful audit result is returned to the user, thus achieving on-chain identity anchoring.

[0101] Dual KYC authentication module:

[0102] like Figure 5 As shown, the first KYC authentication occurs during the user's DID registration phase. After the client collects the user's identity information, it delivers it to the oracle. The oracle queries the user's biometric information from trusted sources (such as public security systems, citizen information systems, etc.) and performs a match. If the match is successful, the KYC authentication information is hashed, encrypted, and stored in the oracle's database. After the user obtains the DID_URL by setting a key, the client delivers it to the oracle for key-value association storage, facilitating simple KYC authentication (i.e., no need for nodes to access external identity data source systems and reach consensus). This achieves a one-to-one anchoring between on-chain distributed digital identity and the user's offline entity.

[0103] like Figure 6As shown, the second KYC verification occurs during the user VC generation phase. The user signs their VC registration request using their distributed digital identity (DID_URL) and uploads their KYC information and MP (identity verification information) for the Certificate Authority (CA). Upon receiving the VC registration request, the client calls the identity resolution contract on the DID chain, accesses the DIDDOC, and verifies the signature's correctness. After successful verification, the client delivers the collected user information to the CA. First, the CA verifies the user's digital identity based on the MP, and simultaneously accesses an oracle to perform simple authentication of the user's ID, completing the trusted binding between the original digital identity system and the user's offline identity. After successful authentication, a local database match is performed, and a VC is generated and signed using a migration tool, then returned to the user. Finally, before the VC credential is uploaded to the chain, the oracle verifies the authenticity of the VC signature. Upon successful verification, the VC is hashed and encrypted, and then the on-chain contract is invoked to associate and store the DID identifier and VC, achieving on-chain notarization.

[0104] The first KYC verification uniquely anchors the user's offline physical identity and distributed digital identity ID. The second KYC verification uniquely anchors the user's traditional digital identity and offline physical identity. These two verifications, using KYC technology and with the user's offline identity verification as a beacon, map the user's traditional digital identity to the distributed digital identity system, ensuring the accuracy and uniqueness of the digital identity system migration.

[0105] VC Batch Registration Module:

[0106] like Figure 7 As shown, the VC batch registration module utilizes database management tools to migrate from traditional digital identities to VC. These tools primarily consist of a database driver manager and database drivers. Database drivers provide APIs to access different databases, while the driver manager is responsible for registering and loading database drivers from different database vendors. For example, when the VC batch registration module is developed using Java, JDBC or other database interaction APIs can be considered. Database drivers are registered and loaded using the `registerDriver` method of the `DriverManager` class. A connection to the database is obtained by providing the database URL, username, and password, and calling the `getConnection` method. After obtaining the `Statement` object, a query is executed using SQL statements, and the result is returned to the application.

[0107] like Figure 8As shown, after the Certificate Authority (CA) completes SCT registration and generates a VC template that conforms to its business logic, it waits for VC registration requests initiated by DID client users. Once the number of user registration requests reaches a threshold (Txs), the CA queries the original system identity (Uid) of the batch-registered users based on the identity verification (MP) provided by the user and accesses the VC batch registration application. Using the certificate holder (DIDi) of the VC to be registered and the user information (Uidi) in the original system as parameters, the CA accesses the statement object returned by the database management tool. Through SQL statements and key-value queries associated with the Uidi, the CA obtains the data value to be migrated (Inf(Uidi.value)). The corresponding Uid values ​​are then batch-imported into the VC using the VC template's key, completing the batch VC registration. The advantage of batch VC registration for distributed digital identity (VC) issuance lies in simplifying the data migration steps for users from traditional digital identities to distributed digital identities. Furthermore, for the CA, only the JDBC program API (database management tool) is needed to achieve batch VC issuance, and the user data of traditional digital identities can be fully utilized, resulting in a simple and smooth process.

[0108] Decentralized Oracle Module:

[0109] like Figure 9As shown, the function of a decentralized oracle is to collect and verify users' offline identity data from an off-chain trusted user identity query system, ensuring the consistency between the user's offline identity and on-chain distributed digital identity before the user possesses a distributed digital identity. It consists of on-chain and off-chain components: the on-chain component includes oracle smart contracts and identity verification smart contracts, while the off-chain component comprises an oracle node pool and a cluster database. Upon receiving an identity verification request, it examines the data packet content; if no DID identifier is found, it executes KYC standard verification. After the oracle retrieves data from an external database, consensus is reached before storage. The consensus process utilizes a threshold signature algorithm: Si is the shard signature for each consensus node, obtained by multiplying the node's private key pki, the aggregate public key P, and the member key Mki on an elliptic curve (i.e., the intersection of the line connecting two points in a finite field with the elliptic curve); the aggregate public key is obtained by nonlinearly adding the public keys: P = a1P1 + a2P2 + a3P3 + ...; the member key Mki is obtained by encrypting each node's identifier using its private key, proving that it is part of that consensus node: Mki = Σj(aj·skj)H(P,i). Before consensus ends, it is necessary to verify how many nodes signed the message. If the number of nodes is less than the threshold or the number of identical messages is less than the threshold, consensus fails, and data must be retrieved from the external database again. If consensus is successful, KYC standard verification begins, and the result is returned to the client. Simultaneously, this information is stored in the local database for simple KYC verification. When a transaction requires obtaining the off-chain identity of the transaction initiator to modify a DID identifier on the blockchain, the identity verification contract sends a call request to the oracle contract. The oracle contract assigns an event ID to each call, signs it, and then executes the request while waiting for the oracle to listen. Upon receiving the event, the oracle performs a simple KYC verification, which involves querying and matching the user's identity information. If this fails, the oracle retrieves the data from an external database, updates the local user data Idp, and matches it again, returning the event verification result.

[0110] Access control module

[0111] Module functionality is based on the following resource-access-permission table:

[0112]

[0113] Table 2 Identity-Permission-Resource Control Table

[0114] The on-chain storage logic for resources is as follows: the identifier field of the DID serves as the user's chain address, and all operations on resources associated with this identifier are implemented by sending transactions. The original DID document exists directly on the chain and is associated with the address. The VC proof, after being hashed, is packaged together with the issuer's digital identity and stored in the user's account.

[0115] There are three roles on the chain with different permissions: C.Admin is the chain management node, which is a node in the basic setup of the DID chain with the function of managing and maintaining on-chain resources. Its functions include: participating in on-chain transaction consensus, DID address verification, DID identity resolution and verification, maintenance and updating of user distributed digital identity related materials, and VC auxiliary verification; O.Admin is the certificate issuing organization administrator. Its off-chain identity is the user identity data manager of the certificate issuing organization, and its on-chain identity is an address with a special DID identifier. Combined with smart contracts, it realizes access to and modification of limited resources on the DID chain. Its functions include: DID identity resolution and verification, signing VC certificates and storing them on the chain, and maintaining and revoking signed VCs; Common is the distributed digital identity ordinary user. On the chain, it exists as an address uniquely bound to its off-chain identity. Its functions include private key signing, selective presentation of VCs, and revocation of VCs.

[0116] (1) Pre-implementation process of the system

[0117] like Figure 10 As shown, the initial process of on-chain digital identity includes the registration, verification, and chain address creation of on-chain digital identities for users and organizations. This is a process of system integration and compatibility with traditional digital identities, mainly including client functions for distributed digital identities. This stage requires the completion of on-chain identity anchoring and identity verification generation for users and organizations, facilitating subsequent system management and maintenance. The organization refers to a Certificate Authority (CA) organization. In a CA organization, "certificate" refers to a digital certificate in the existing digital identity system, specifically a digital file in the PKI system that is digitally signed by a certification authority and contains information about the public key owner, the public key, the issuer, the validity period, and some extended information, used to prove the identity of the key owner. The user is the person using the client to conduct DID system-related business; the client is the front-end system used in this invention for interoperation with the user.

[0118] Step S1.1: The user provides initial KYC verification and an encryption method for on-chain digital identity registration. After the oracle verifies the authentication information, the private key is encrypted using hashing and elliptic curve cryptography to generate a DID identifier field. When generating the initial chain address, on-chain contract verification is required before use; therefore, the generated DID identifier field is used as the proposed on-chain address. The encryption method is a key generation algorithm selected by the user, including but not limited to: SM2, RSA, and ECDHE.

[0119] In step S1.2, the chain management node verifies the legitimacy of the identity registration request received from the oracle, including address legitimacy and uniqueness verification. If the legitimacy verification fails, a registration failure result is returned; otherwise, a globally unique DID identifier is generated based on the DID project name and chain ID of the identity chain and returned to the user. At the same time, an on-chain ordinary user address is created for this digital identity.

[0120] In step S1.3, the chain management node packages the user's authentication method and public key array into a DID document, sends it to the user's address in the form of a transaction, and persistently stores it on the chain.

[0121] In step S1.4, the organization sends registration data to the oracle, along with its organizational identity certificate and a list of administrators. The chain management node verifies the organization's on-chain identity legitimacy as per step S1.2. Upon successful verification, it returns to step S1.3 to generate a DID document for the organization and save the organization's administrator identity. Optionally, the endorsement signature of the superior organization can be attached to the materials provided by the client to the oracle.

[0122] In step S1.5, if the organization provided an endorsement signature from its parent organization in S4, then after step S1.4 is completed, the organization's identity is mounted to the parent node through the organization mounting contract to facilitate access control.

[0123] Step S1.6: The organization applies to the SCT registration module on the client for VC declaration types that conform to its business logic, and registers the data structure and verification method to the VC integration module.

[0124] Step S1.7: The organization broadcasts a signed VC bulk registration notification to users and sends its own on-chain digital identity address to the original system users for user verification.

[0125] Step S1.8: The user provides the organization with digital identity and KYC authentication information for secondary KYC authentication, which associates and binds the user's off-chain identity, on-chain identity and the organization's VC declaration.

[0126] In step S1.9, the organization will use the SCT template registered in step S1.6 to uniformly generate VCs that are interoperable between different DID solutions by reviewing and approving the integrated user certificate information, and return them to the user for storage off-chain.

[0127] In step S1.10, the organization verifies the batch data after VC integration through an oracle and outputs a VC digest, which is then sent to the account address of the VC user and stored on the chain to be associated with the user.

[0128] (2) Post-implementation process of the system

[0129] The on-chain digital identity post-processing function manages and maintains on-chain resources. These resources include user DIDs, DID documents, VC proofs, and organizational hierarchy trees. The process is divided into DID management and VC management based on corresponding resource access control permissions. DID management aims to modify a user's DID information while ensuring the uniqueness of their on-chain address, including adding public key arrays or resetting private keys. VC management aims to enable CRUD operations on issued certificates by the organization when an organization or user's identity becomes invalid, as well as VC redirection in the event of organization failure.

[0130] (1) DID Management

[0131] Step S2.1: The user submits a DID modification request to the on-chain management node.

[0132] In step S2.2, the on-chain management node calls the authentication contract, passing the user's DID identifier and identity credentials into the contract.

[0133] Step S2.3: The authentication contract calls the oracle contract. The oracle contract assigns an event ID to each call and executes the process after signing, waiting for the oracle to listen.

[0134] Step S2.4: The oracle listens to on-chain events and matches and verifies them based on the data generated by consensus. If it fails, it retrieves data from the outside again and reaches consensus.

[0135] In step S2.5, the message verified by the oracle is transmitted to the chain, the administrator node reviews the legality of the application, and returns the data type required by the interface to the user.

[0136] In step S2.6, the user uploads the new public key or new digital identity address to the chain. After consensus by the administrator node, the corresponding DID document is modified or a new chain address is added.

[0137] (2) VC Management

[0138] In step S2.7, the user applies for a VC off-chain from the organization, and after KYC verification, stores it locally and sends a VC summary to the user's account address for storage on the chain.

[0139] In step S2.8, when a user VC becomes invalid or is changed, the issuing organization updates the content and validity status of the user VC off-chain.

[0140] Step S2.9: The updated VC is encrypted and uploaded to the blockchain and sent to the user address to store the proof digest.

[0141] Step S2.10: When an organization fails, the superior organization manager accesses the organization's mounting management contract, deletes the node address in the chain's hierarchical tree, and mounts the child nodes onto this node to maintain the hierarchical relationship.

[0142] Step S2.11: The VC issued by the invalid organization modifies the issuing party to the digital identity address of the superior organization according to the organization's mounting contract, and updates the corresponding verification method and service node in the VC to achieve redirection.

[0143] Step S2.12: Send the updated VC to the user via the oracle contract, store the updated VC locally, and store the proof digest on the chain.

[0144] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.

[0145] This invention also proposes a highly integrated, general-purpose distributed digital identity authentication management system, in which users and organizations complete digital identity registration, verification, and chain address creation on the blockchain, specifically including:

[0146] Module 1: Users provide initial KYC proof and encryption methods to register their digital identity on the chain. After the oracle verifies the authentication information, the private key is encrypted using hash and elliptic curve cryptography to generate a DID identifier field as the on-chain address, and an identity registration request is sent to the chain management node.

[0147] Module 2: The chain management node verifies the legality of the identity registration request. If the verification fails, it returns a registration failure result. If the verification passes, it generates a globally unique DID identifier based on the DID project name and chain ID of the identity chain and returns it to the user. At the same time, it creates an on-chain user address for the digital identity.

[0148] Module 3: The chain management node packages the user's authentication method and public key array information into a DID document and sends it to the user's address in the form of a transaction for persistent storage on the chain.

[0149] Module 4: The organization sends registration data to the oracle, along with its identity certificate and a list of administrators; the chain management node verifies the organization's identity on the chain, generates a DID document for the organization, and saves the organization's administrator identity.

[0150] Module 5: The organization applies to the SCT registration module on the client side for VC declaration types that conform to its own business logic, and registers the data structure and validation method to the VC integration module;

[0151] Module 6: Organize a signed VC bulk registration notification broadcast to users and send its own on-chain digital identity address to the original system users for user verification;

[0152] Module 7: Users provide digital identity and KYC authentication information to the organization for secondary KYC authentication, linking and binding the user's off-chain identity, on-chain identity, and organization VC declaration;

[0153] Module 8: The organization will use the VC integration module to uniformly generate VCs that are interoperable across all DID solutions, based on the user certificate information that has been reviewed and approved for integration, and return them to the user for storage off-chain.

[0154] Module 9: The organization verifies the batch data after VC integration through an oracle, outputs a VC digest, and sends it to the account address of the VC user, storing it on the chain and associating it with the user.

[0155] The present invention also proposes a storage medium for storing a program that executes any of the highly integrated general-purpose distributed digital identity authentication management methods.

[0156] The present invention also proposes a client for the aforementioned highly integrated general-purpose distributed digital identity authentication management system.

Claims

1. A highly integrated, universally distributed digital identity authentication management method, characterized in that, Users and organizations complete digital identity registration, verification, and blockchain address creation on-chain, specifically including: Step 1: The user provides initial KYC proof and encryption method to register an on-chain digital identity. After the oracle verifies the authentication information, the private key is encrypted using hash and elliptic curve cryptography to generate a DID identifier field as an on-chain address, and an identity registration request is sent to the chain management node. Step 2: The chain management node verifies the legality of the identity registration request. If the verification fails, a registration failure result is returned. If the verification passes, a globally unique DID identifier is generated based on the DID project name and chain ID of the identity chain and returned to the user. At the same time, an on-chain user address is created for the digital identity. Step 3: The chain management node packages the user's authentication method and public key array information into a DIDDOC, and sends it to the user's address in the form of a transaction for persistent storage on the chain. Step 4: The organization sends registration data to the oracle, along with its identity certificate and a list of administrators; the chain management node verifies the organization's identity on the chain, generates a DIDDOC for the organization, and saves the organization's administrator identity. Step 5: The organization applies to the SCT registration module on the client side for VC declaration types that conform to its own business logic, and registers the data structure and verification method to the VC integration module; Step 6: Organize a signed VC bulk registration notification broadcast to users and send your on-chain digital identity address to the original system users for user verification; Step 7: Users provide digital identity and KYC verification information to the organization for secondary KYC verification, linking and binding the user's off-chain identity, on-chain identity, and organization VC declaration; Step 8: The organization will use the VC integration module to uniformly generate VCs for all DID solutions to be interoperable, based on the user certificate information that has been reviewed and approved for integration, and return them to the user for storage off-chain. Step 9: The organization verifies the batch data after VC integration through an oracle, outputs a VC digest, and sends it to the account address of the VC user, storing it on the chain and associating it with the user.

2. The highly integrated, universally distributed digital identity authentication management method as described in claim 1, characterized in that, The on-chain resources are managed and maintained, including user DIDs, DIDDOCs, VC proofs, and organizational hierarchical trees. The process is divided into DID management and VC management according to the corresponding resource access control permissions. Specifically, DID management includes: Step 10: The user submits a DID modification request to the on-chain management node; Step 11: The on-chain management node calls the authentication contract, passing the user's DID identifier and identity credentials into the contract; Step 12: The authentication contract calls the oracle contract. The oracle contract assigns an event ID to each call and executes it after signing, waiting for the oracle to listen. Step 13: The oracle listens for on-chain events and matches and verifies them based on the data generated by consensus. If it fails, it retrieves data from the outside again and reaches consensus. Step 14: The message verified by the oracle is transmitted to the chain. The administrator node reviews the legality of the application and returns the data type required by the interface to the user. Step 15: The user uploads the new public key or new digital identity address to the chain. After consensus by the administrator node, the corresponding DIDDOC or the new chain address is modified. This VC management specifically includes: Step 16: The user applies for VC off-chain from the organization, and after KYC verification, it is stored locally and the VC summary is sent to the user's account address and stored on the chain. Step 17: When a user VC expires or is changed, the issuing organization updates the content and validity status of the user VC off-chain. Step 18: Upload the updated VC to the blockchain using an encryption algorithm and send it to the user address to store the proof digest; Step 19: When an organization fails, the superior organization manager accesses the organization's management contract, deletes the node address of the chain management node in the chain's hierarchical tree, and attaches child nodes to this node to maintain the hierarchical relationship. Step 20: The VC issued by the invalid organization is modified to the digital identity address of the superior organization according to the organization's mounting contract, and the corresponding verification method and service node in the VC are updated to achieve redirection. Step 21: Send the updated VC to the user via the oracle contract. Store the updated VC locally and store the proof digest on the chain.

3. The highly integrated, universally distributed digital identity authentication management method as described in claim 1, characterized in that, Step 1 includes: When a user registers on the client, after verifying their mobile phone number, they enter the KYC authentication stage. The user provides identity information IDi and biometric information IDp. After collecting the biometric information, the client forwards the authentication request to the oracle. The oracle uses IDi to look up and verify the user's offline identity and returns the result to the client to achieve off-chain identity anchoring. After receiving the successful return result, the client notifies the user to set a key. The user selects encryption method M1. The client calls the corresponding asymmetric cryptography generator and generates a distributed digital identity DID_URL and DIDDOC based on the generated public key PA and the encryption method M1 selected by the user. The private key dA is returned to the user and stored locally. After obtaining the DID_URL, the client delivers the DID_URL and identity document to the oracle for trusted data verification. After successful verification, the data is uploaded to the blockchain, where the audit contract performs a unique identity verification check. After the check passes, the DID_URL and DIDDOC are associated and stored on the blockchain, and the successful verification result is returned to the user, achieving on-chain identity anchoring.

4. The highly integrated, universally distributed digital identity authentication management method as described in claim 1, characterized in that, The methods for KYC verification in step 1 include: After the client collects the user's identity information, it delivers it to the oracle. The oracle queries the user's biometric information from a trusted source based on the user's identity and performs a match. If the match is successful, the KYC authentication information is hashed, encrypted, and stored in the oracle's database. After the user obtains the DID_URL by setting a key, the client delivers it to the oracle for key-value pair Kv association storage to facilitate KYC authentication. The methods for secondary KYC verification in step 7 include: Users sign their VC registration requests using a distributed digital identity (DID_URL) and upload their KYC information and MP (identity verification information) for the Certificate Authority (CA). Upon receiving the VC registration request, the client calls the identity resolution contract on the DID chain to access the DID DOC and verify the signature's correctness. After successful verification, the client delivers the collected user information to the CA. The CA first verifies the user's digital identity based on the MP and simultaneously accesses an oracle to perform simple authentication of the user's IDi, completing a trusted binding between the original digital identity system and the user's offline identity. After successful binding, a local database match is performed, and a VC is generated and signed using migration tools, then returned to the user. Finally, before the VC credential is uploaded to the chain, the oracle verifies the authenticity of the VC signature. Upon successful verification, the VC is hashed and encrypted, and then the on-chain contract is invoked to associate and store the DID identifier and the VC.

5. The highly integrated, universal distributed digital identity authentication management method as described in claim 1, characterized in that, Step 6 includes: After generating a VC template that conforms to its business logic through SCT registration, the Certificate Authority (CA) waits for VC registration requests initiated by DID client users. Once the number of user registration requests reaches the threshold Txs, the CA queries the original system identity Uid of the batch-registered users based on the identity proof MP provided by the user and accesses the VC batch registration application. Using the certificate holder DID and the user information Uidi from the original system as parameters, the CA accesses the statement object returned by the database management tool. Through SQL statements and key-value queries associated with the user information Uidi, the CA obtains the data value Inf that needs to be migrated. Finally, the CA imports the corresponding Uid value into the VC in batches using the VC template's Key, completing the VC batch registration.

6. The highly integrated, universally distributed digital identity authentication management method as described in claim 1, characterized in that, This oracle is used to collect and verify users' offline identity data from an off-chain trusted user identity query system, ensuring the consistency between users' offline identity and on-chain distributed digital identity before users have a distributed digital identity. The oracle is divided into on-chain and off-chain parts: the on-chain part includes the oracle smart contract and the authentication smart contract, and the off-chain part consists of the oracle node pool and the cluster database; when an authentication request is received, the content of the data packet is judged, and if there is no DID identifier, KYC standard verification is performed; after the oracle obtains data from the external database, consensus needs to be reached before storage. The consensus process uses the threshold signature algorithm: Si is the shard signature of each consensus node, which is obtained by multiplying the node's private key pki, the aggregate public key P, and the member key Mki on an elliptic curve; The aggregate public key is obtained by non-linearly adding the public keys. The member key Mki is obtained by encrypting each node's ID using its private key, proving that it is part of the consensus node. Before the consensus ends, it is necessary to verify how many nodes signed the data obtained from the external database. If the number of nodes is less than the threshold or the number of identical messages is less than the threshold, the consensus fails and the data needs to be obtained from the external database again. If the consensus is successful, KYC standard verification begins, and the result is returned to the client. At the same time, the data obtained from the external database is stored in the local database for KYC verification. When a DID identifier on the chain needs to modify the business and obtain the off-chain identity of the transaction initiator, the identity verification contract sends a call request to the oracle contract. The oracle contract assigns an event ID to each call and executes it after signing, waiting for the oracle to listen. After the oracle listens for the event, it performs KYC verification. If it fails, it retrieves the data from the external database again, updates the local user data Idp, matches it again, and returns the event verification result.

7. The highly integrated, universal distributed digital identity authentication management method as described in claim 1, characterized in that, Step 4 includes: attaching the endorsement signature of the superior organization to the materials provided by the client to the oracle; and attaching the organization's identity to the parent node through the organization mounting contract.

8. A highly integrated, universally distributed digital identity authentication management system, characterized in that, Users and organizations complete digital identity registration, verification, and blockchain address creation on-chain, specifically including: Module 1: Users provide initial KYC proof and encryption methods to register their digital identity on the chain. After the oracle verifies the authentication information, the private key is encrypted using hash and elliptic curve cryptography to generate a DID identifier field as the on-chain address, and an identity registration request is sent to the chain management node. Module 2: The chain management node verifies the legality of the identity registration request. If the verification fails, it returns a registration failure result. If the verification passes, it generates a globally unique DID identifier based on the DID project name and chain ID of the identity chain and returns it to the user. At the same time, it creates an on-chain user address for the digital identity. Module 3: The chain management node packages the user's authentication method and public key array information into a DIDDOC and sends it to the user's address in the form of a transaction for persistent storage on the chain. Module 4: The organization sends registration data to the oracle, along with its identity certificate and a list of administrators; the chain management node verifies the organization's identity on the chain, generates a DIDDOC for the organization, and saves the organization's administrator identity. Module 5: The organization applies to the SCT registration module on the client side for VC declaration types that conform to its own business logic, and registers the data structure and validation method to the VC integration module; Module 6: Organize a signed VC bulk registration notification broadcast to users and send its own on-chain digital identity address to the original system users for user verification; Module 7: Users provide digital identity and KYC authentication information to the organization for secondary KYC authentication, linking and binding the user's off-chain identity, on-chain identity, and organization VC declaration; Module 8: The organization will use the VC integration module to uniformly generate VCs that are interoperable across all DID solutions, based on the user certificate information that has been reviewed and approved for integration, and return them to the user for storage off-chain. Module 9: The organization verifies the batch data after VC integration through an oracle, outputs a VC digest, and sends it to the account address of the VC user, storing it on the chain and associating it with the user.

9. A storage medium for storing a program that executes the highly integrated general distributed digital identity authentication management method as described in any one of claims 1 to 7.

10. A client for use in the highly integrated general-purpose distributed digital identity authentication management system of claim 8.

Images