Distributed digital identity account processing method and device and electronic equipment

Abstract

The invention relates to the technical field of information security and cryptography, and provides a distributed digital identity account processing method and device and electronic equipment. The method comprises the following steps: receiving an alias registration request sent by a first QVI mechanism; creating a user account tree based on the first account association information corresponding to the first user; the user account tree is a Merkel tree comprising at least one pair of leaf nodes, determining a first alias corresponding to the first user, binding the first alias with the user account tree, and generating a first identity certificate; at least combining the first root hash signature value of the user account tree with the hash value of the first identity certificate to generate a first association record, and synchronously storing the first association record in the block chain; and determining a corresponding user account tree according to the to-be-verified alias carried in the query request, generating a zero-knowledge proof based on the user account tree, and at least returning the zero-knowledge proof to the second user. According to the technical scheme, the AID account verification process can be simplified, and the user experience is improved.

Description

Technical Field

[0001] This invention relates to the fields of information security and cryptography, and in particular to a method, apparatus and electronic device for processing distributed digital identity accounts. Background Technology

[0002] A Verifiable Legal Entity Identifier (vLEI) is a verifiable legal entity identifier designed to provide verifiable digital identities for entities in the digital world. An Autonomic Identifier (AID) is a self-managed, anonymous identifier. In the current vLEI system, when two users holding AID accounts establish a connection for the first time, the standard verification process involves both parties performing a challenge / response process to confirm the other's true identity and prevent man-in-the-middle attacks. This process requires two rounds, with each participant taking turns as both the challenger and the challenged. In addition to the standard verification process, depending on the needs of certain scenarios, the AID account verification process may also involve verifying the other party's identity documents, making the AID account verification process extremely cumbersome, especially when a user holds multiple AID accounts. In such cases, the user needs to perform a challenge / response process for each of their AID accounts, resulting in a poor user experience. Summary of the Invention

[0003] This application provides a distributed digital identity account processing method, apparatus, and electronic device, which enables the management of multiple AID accounts based on a single alias, simplifies the verification process, and improves user experience.

[0004] This application provides a distributed digital identity account processing method, which includes: receiving an alias registration request for a first user sent by a first QVI institution; creating a user account tree based on the first account association information corresponding to the first user carried in the alias registration request; the first account association information includes the first account registered by the first user with the first QVI institution; the user account tree is a Merkle tree including at least one pair of leaf nodes, and the first pair of leaf nodes is used to record the first account association information; the first account is an AID account or a DID account; determining a globally unique first alias corresponding to the first user, and associating the first alias with the user account... The first identity credential is generated by binding the first account tree and generating a first identity credential. The extended field of the first identity credential includes a first alias. The hash signature value of the first root of the user account tree and the hash value of the first identity credential are combined to generate a first association record, and the first association record is synchronously stored in the blockchain. In response to receiving a query request submitted by the second user, the corresponding user account tree is determined according to the alias to be verified carried in the query request. A zero-knowledge proof is generated based on the user account tree, and the first account, the zero-knowledge proof, and the first identity credential are returned to the second user to trigger the second user to verify the first account held by the first user based on the zero-knowledge proof and the first association record queried from the blockchain.

[0005] A distributed digital identity account processing method provided in this application generates zero-knowledge proofs based on a user account tree, including: determining the target account corresponding to the alias to be verified; the target account is a default account or an account specified by additional information carried in the query request; generating a zero-knowledge proof based on the target leaf node corresponding to the target account in the user account tree; the zero-knowledge proof includes the hash values ​​of each sibling node on the Merkel path from the target leaf node to the root node of the user account tree, and the hash value of the target leaf node.

[0006] According to an embodiment of this application, a distributed digital identity account processing method is provided, wherein the target account is a default account; or, the query request also carries additional information; and the target account is the account specified by the additional information.

[0007] According to an embodiment of this application, a distributed digital identity account processing method is provided, wherein the alias registration request also carries first identity material information corresponding to the first user; the first identity material information includes at least one identity attribute information; the method further includes: creating a user identity tree based on the identity material information; the user identity tree is a Merkle tree including at least one leaf node, and at least one leaf node corresponds one-to-one with at least one identity attribute information; at least the first root hash signature value of the user account tree and the hash value of the first identity credential are combined to generate a first association record, including: combining the root hash signature value of the user identity tree, the first root hash signature value of the user account tree and the hash value of the first identity credential to generate a first association record.

[0008] According to an embodiment of this application, a distributed digital identity account processing method is provided, which further includes: in response to receiving an alias registration request for a first user sent by a second QVI institution, and if it is determined from the first identity material information that the first user has already registered a first alias, creating a second pair of leaf nodes in the user account tree corresponding to the first user; the second pair of leaf nodes are used to record second account association information; the second account association information includes the second account registered by the first user with the second QVI institution; binding the first account, the second account, and the first alias; after creating the second pair of leaf nodes, re-determining the second root hash signature value of the user account tree; combining the root hash signature value of the user identity tree, the second hash signature value of the user account tree, and the hash value of the first identity credential to generate a second association record; synchronously storing the second association record on the blockchain; and returning the query address of the second association record on the blockchain to the second QVI institution.

[0009] According to an embodiment of this application, a distributed digital identity account processing method is provided, which further includes: in response to receiving an unbinding request for a first user sent by a second QVI institution, unbinding the second account from the first alias; deleting a second pair of leaf nodes from the user account tree corresponding to the first user, and re-determining the third root hash signature value of the user account tree; combining the root hash signature value of the user identity tree, the third root hash signature value of the user account tree, and the hash value of the first identity credential to generate a third association record; synchronously storing the third association record on the blockchain; and returning the query address of the third association record on the blockchain to the second QVI institution.

[0010] According to an embodiment of this application, a distributed digital identity account processing method further includes: responding to receiving an identity information update request for a first user sent by a first QVI institution, verifying the updated second identity material information carried in the identity information update request and the authenticity of the first user; if the verification is successful, updating the identity attribute information recorded in the corresponding leaf node in the user identity tree; determining the root hash signature value of the updated user identity tree; combining the root hash signature value of the updated user identity tree, the root hash signature value of the user account tree, and the hash value of the first identity credential to generate a fourth association record; synchronously storing the fourth association record on the blockchain; and returning the query address of the fourth association record on the blockchain to the first QVI institution.

[0011] According to an embodiment of this application, a distributed digital identity account processing method further includes: responding to receiving an alias update request for a first user sent by a first QVI institution, verifying the first identity material information carried in the alias update request and the authenticity of the first user; if the verification is successful, querying whether the second alias carried in the alias update request has been registered; if the second alias has been registered, re-obtaining the third alias corresponding to the first user; if the second alias has not been registered, generating a second identity credential; the extended field of the second identity credential includes the second alias; combining at least the root hash signature value of the user account tree and the hash value of the second identity credential to generate a fifth association record, and synchronously storing the fifth association record on the blockchain; and returning the query address of the fifth association record on the blockchain to the first QVI institution.

[0012] According to an embodiment of this application, a distributed digital identity account processing method is provided, which further includes: responding to receiving an authentication request for a first user sent by a first QVI institution; verifying the authenticity of the first user, and if the verification is successful, querying whether the alias to be verified carried in the authentication request exists; the authentication request is generated by the first QVI institution in response to a request to issue vLEI credentials initiated by the first user; if the alias to be verified exists, determining the target account corresponding to the alias to be verified; generating a first zero-knowledge proof based on the target leaf node corresponding to the target account in the user account tree; determining the target leaf node corresponding to the user identity attribute information in the user identity tree based on the user identity attribute information required for issuing vLEI credentials carried in the authentication request, and generating a second zero-knowledge proof based on the target leaf node; and returning the real identity attribute information recorded in the target leaf node, the target account, the target association information corresponding to the target account, the first zero-knowledge proof, and the second zero-knowledge proof to the first QVI institution.

[0013] According to an embodiment of this application, a distributed digital identity account processing method is provided. The method further includes: responding to receiving an identity query request for a first user sent by a second user; querying whether an alias to be verified carried in the identity query request exists; the identity query request is used to verify the authenticity of the vLEI credential and alias held by the first user; if the alias to be verified exists, determining the target account corresponding to the alias to be verified; generating a third zero-knowledge proof based on the target leaf node corresponding to the target account in the user account tree; and returning the target account and the third zero-knowledge proof to the second user to trigger the second user to verify the authenticity of the vLEI credential and alias held by the first user based on the third zero-knowledge proof and a first association record queried from the blockchain.

[0014] This application embodiment also provides a distributed digital identity account processing device, which includes: a receiving unit, configured to receive an alias registration request for a first user sent by a first QVI institution; a Merkle tree creation unit, configured to create a user account tree based on the first account association information corresponding to the first user carried in the alias registration request; the first account association information includes the first account registered by the first user with the first QVI institution; the user account tree is a Merkle tree including at least one pair of leaf nodes, and the first pair of leaf nodes in the at least one pair of leaf nodes is used to record the first account association information; and a generation unit, configured to determine a globally unique first alias corresponding to the first user and generate a first... The identity credential includes an extended field of a first alias; an association unit, used to combine at least the first root hash signature value of the user account tree and the hash value of the first identity credential to generate a first association record, and synchronously store the first association record on the blockchain; and a verification unit, used to respond to a query request submitted by a second user, determine the corresponding user account tree based on the alias to be verified carried in the verification request, generate a zero-knowledge proof based on the user account tree, and return the first account, the zero-knowledge proof, and the first identity credential to the second user, so as to trigger the second user to verify the first account held by the first user based on the zero-knowledge proof and the first association record queried from the blockchain.

[0015] This application also provides an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the distributed digital identity account processing method as described above.

[0016] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the distributed digital identity account processing method as described above.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements a distributed digital identity account processing method as described above.

[0018] The distributed digital identity account processing method, apparatus, and electronic device provided in this application embodiment allow a first user to register a first AID account with a first QVI institution. After the first user registers a first AID account with a first QVI institution, they can send an alias registration request to a designated CA institution (defined as an alias management platform). The alias management platform creates a user account tree based on the first AID account association information carried in the alias registration request. The user account tree is a Merkle tree including at least one pair of leaf nodes. The first pair of leaf nodes records the first AID account association information, which includes the first AID account. That is, one pair of leaf nodes in the user account tree corresponds to one AID account, and one user account tree can manage multiple AID accounts. Then, a globally unique first alias corresponding to the first user is determined, and the first alias is bound to the user account tree, generating a first identity credential. One user account tree can be bound to only one alias, thus enabling the binding of multiple AID accounts based on one alias. Then, at least the hash signature value of the first root of the user account tree and the hash value of the first identity credential are combined to generate a first association record, which is synchronously stored on the blockchain. When a second user needs to connect with a holder of the first AID account... When the first user conducts a transaction or engages in other business cooperation, the second user can send a query request to the alias management platform. The alias management platform determines the corresponding user account tree based on the alias to be verified carried in the verification request. Then, it generates a zero-knowledge proof based on the user account tree and returns the first account, the zero-knowledge proof, and the first identity credential to the second user. The second user can then verify the first account held by the first user based on the zero-knowledge proof and the first association record retrieved from the blockchain. This verification process only requires the user to trigger the corresponding verification process. It does not require the first user and the second user to perform a challenge / response process to each other, nor does it require the first user and the second user to take turns acting as the challenger and the challenged party. Furthermore, it does not require the first user or the second user to verify the other party's identity materials, thus simplifying the user operation in the verification process. Moreover, when the first user holds multiple AID accounts, the authenticity verification of different AID accounts can be carried out using the above method. In this way, the first user only needs to provide the other party (the second user) with an alias to realize the verification of multiple AID accounts. This not only greatly simplifies the user operation in the verification process but also solves the data silo problem of multiple AID accounts being supervised by different QVI institutions, significantly improving the user experience. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this application 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the distributed digital identity account processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a Merkle tree in one embodiment of the distributed digital identity account processing method provided in this application; Figure 3 This is a schematic diagram of the user account tree initially created in one embodiment of the distributed digital identity account processing method provided in this application; Figure 4 This is a schematic diagram illustrating an example of a user identity tree in one embodiment of the distributed digital identity account processing method provided in this application. Figure 5 This is a schematic diagram of the alias registration and verification process in one embodiment of the distributed digital identity account processing method provided in this application. Figure 6 This is an example diagram of a user identity tree in one embodiment of the distributed digital identity account processing method provided in this application. Figure 7 This is a schematic diagram of the process of updating the user account tree in one embodiment of the distributed digital identity account processing method provided in this application; Figure 8 This is a schematic diagram illustrating identity information updating in one embodiment of the distributed digital identity account processing method provided in this application. Figure 9 This is a schematic diagram of an alias update process in one embodiment of the distributed digital identity account processing method provided in this application. Figure 10 This is a schematic diagram illustrating the process of assisting the QVI organization in verifying the user's identity and account information before issuing a vLEI credential to the user in one embodiment of the distributed digital identity account processing method provided in this application. Figure 11 This is a schematic diagram of the vLEI credential ownership verification process in one embodiment of the distributed digital identity account processing method provided in this application. Figure 12 This is a schematic diagram of the software module structure of the distributed digital identity account processing device provided in the embodiments of this application; Figure 13This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone, where A and B can be singular or plural. In the textual description of this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0023] To facilitate understanding, a brief explanation of the relevant technical terms used in this application specification will be provided first.

[0024] Decentralized Identity (DID) is a cryptographic technique that enables individuals and organizations to create and control their own unique identifiers, obtain verifiable credentials from trusted organizations, and present portions of the credentials as proof of claims without relying on centralized service providers or intermediaries.

[0025] A DID (Digital Identity Registry) is a specific string used to represent the digital identity of an entity, which can be a person, machine, or thing. The format of a DID is: `did:example:123456789abcdefghi`, where the prefix "did:" is fixed and identifies the string as a DID; the middle part, "example," is called the DID method, indicating which scheme (method) was used to define and operate the DID (DID methods can be customized and registered on the W3C website); and the last part, "123456789abcdefghi," is a unique identifier string under that DID method.

[0026] DID Document: Each DID identifier corresponds to a DID document. The DID document consists of a set of data describing the DID subject, which typically includes an identifier, a public key, and timestamps for document creation and updates. This allows the DID subject or authorized person to use these mechanisms for authentication and to prove their association with the DID.

[0027] An identifier is a unique reference that points to and distinguishes a specific entity, resource, or identity within a specific scope. It enables unambiguous identification without requiring human-readable meaning or relying on centralized registration.

[0028] An Autonomic Identifier (AID) is a distributed digital identity identifier implemented based on the KERI protocol. Its function corresponds to the DID (Decentralized Identifier) ​​defined in the W3C standard. As a unique identifier for a user in the digital world, the AID is bound to the user's real identity information and achieves autonomous control over the identifier through a Key Event Log (KEL).

[0029] Key Event Receipt Infrastructure (KERI) is a protocol specification that utilizes self-certified identifiers, cryptographically verifiable key event logs (KELs), and innovative key rotation mechanisms to build a decentralized key management infrastructure (DKMI). This enables secure, portable, and end-user-verifiable control over digital identifiers without relying on centralized institutions or blockchains.

[0030] The Key Event Log (KEL) is a verifiable, append-only, and cryptographically linked data structure used to record all key events of an Autonomous Identifier (AID), providing a complete and tamper-proof history of key state changes from creation to rotation and interaction.

[0031] Key events are serialized data structures in the Key Event Log (KEL) that represent atomic state transitions and are used to establish or modify the authoritative key state of an Autonomous Identifier (AID). Each key event is cryptographically signed and linked to previous events to form a verifiable, append-only history of control.

[0032] The Verifiable LEI (vLEI) is a cryptographically secure verifiable credential (VC) issued by a QVI authority that complies with the GLEIF governance framework. It provides a non-repudiable and machine-verifiable proof of a legal entity's identity and associates the LEI with a KERI-based Autonomous Identifier (AID) through ACDC credential technology.

[0033] GLEIF (Global Legal Entity Identifier Foundation) manages and maintains the LEI system, ensuring the uniqueness, accuracy, and global applicability of LEIs, and providing verification and query services. GLEIF operates the Global Legal Entity Identifier System (GLEIS) and serves as the root of trust for the verifiable legal entity identifier (vLEI) ecosystem.

[0034] A QVI (Qualified vLEI Issuer) is a GLEIF-accredited organization authorized to issue and verify vLEIs, ensuring their compliance with standards and regulations. A QVI is a GLEIF-certified entity authorized to create and issue verifiable True Chained Data Container (ACDC) credentials, make assertions about entities, and transfer credentials to the holder. Its Self-Determined Identifier (AID) is located at the top level of the ACDC structure.

[0035] LE (Legal Entities) refers to a company, institution, or organization that needs to obtain a vLEI.

[0036] ACDC (Authentic Chained Data Container) is a protocol specification for creating verifiable chained data containers that form a directed acyclic graph (DAG) and have cryptographically verifiable signature proofs, thereby enabling secure, privacy-preserving verifiable credentials based on the KERI infrastructure.

[0037] A Legal Entity Identifier (LEI) is a 20-digit alphanumeric code conforming to the ISO 17442 standard, used to uniquely identify legally registered organizations worldwide. It is the cornerstone of GLEIF's verifiable LEI (vLEI) credential ecosystem built on the KERI infrastructure.

[0038] A verifiable credential (VC) is a cryptographically protected digital credential that contains a claim about the subject, is issued by the issuer, held by the holder, and can be verified by any verifier without access to the issuer.

[0039] Out-of-band introduction (OOBI) is a core concept in the KERI / vLEI system. OOBI is a discovery mechanism that associates a KERI discretionary identifier (AID) with a network address (URL). This mechanism associates the URL with either a KERI discretionary identifier (AID) or a self-addressing identifier (SAID).

[0040] OOR (Official Organizational Role) describes an entity’s role or function within a specific organizational structure, such as a director or manager, and is used to clarify the responsibilities and relationships within the entity.

[0041] ECR (Engagement Context Role) defines the role of an entity in a specific collaboration or transaction, such as a partner, customer, or supplier, and is used to describe the entity's behavior and relationships in a specific context.

[0042] vLEI Credentials: The vLEI system is used not only to identify organizations but also to associate individuals with organizations through specific digital credentials (vLEI credentials). vLEI credentials strictly adhere to the ISO 5009 standard, and their goal is to bind organizations to natural persons and their organizational roles or employment relationships.

[0043] Distributed Digital Identity (DID) is a new technological framework that restructures traditional centralized identity management. Its core lies in using technologies such as blockchain and cryptography to enable customers to have complete control over their personal identity data, without relying on third-party institutions (such as governments or enterprises) as trusted intermediaries. Each customer possesses a unique decentralized identifier and can prove their identity attributes (such as age, professional qualifications, etc.) without exposing the original data through verifiable credentials (VC). For example, when applying for services from institutions such as banks, customers only need to submit a cryptographically signed "good credit" certificate, without providing their entire transaction history.

[0044] Blockchain is a decentralized database that combines computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, it's a distributed ledger maintained by multiple nodes, where data is packaged into blocks in chronological order and linked together in an immutable chain structure using hash values. The core characteristics of blockchain include decentralization, data immutability, transparency and traceability, and high security. This technology is now widely used in finance, government affairs, supply chain, and many other fields. Simply put, blockchain can be understood as a public ledger system with universal participation. All transaction records are synchronized to every node in the network, and a consensus mechanism ensures data consistency and security. A blockchain address is a user's identity identifier within the blockchain network, much like a bank account number. It typically consists of a string of characters; for example, a blockchain address could be in the form of "0xc0ffee254729296a45a3885639AC7E10F9d54979".

[0045] In blockchain or distributed digital identity (DID) systems, an alias typically refers to a human-readable and easy-to-remember identifier used to replace complex blockchain addresses or DID identifiers and represent a digital identity or entity. It's similar to a traditional username or nickname. For example, blockchain address aliasing aims to allow users to use easy-to-remember names instead of complex addresses, which not only improves user experience but also further reduces the risk of human error in manually entering addresses. However, current alias management technologies have several problems, including: (1) The AID account verification process in the vLEI system is too complicated: In related technologies, under the vLEI system, when two users holding AID accounts establish a connection for the first time, they need to perform a challenge / response process on each other to verify the other party's true identity and prevent man-in-the-middle attacks. Specifically, the two AID users first need to send their AID account addresses to each other via online chat, either as a string or a QR code. Then, the other party accesses OOBI to obtain and parse the Key Event Log (KEL) associated with the AID. After both parties have completed parsing the other party's key event, one party acts as the challenger and generates a set of random challenge words (such as 6 or 12 English words). Then, in a video-connected environment, the challenger sends the challenge words to the other party via online chat. The other party, as the challenged party, signs the hash value of the challenge words using the private key associated with their AID account after receiving the challenge words, and then returns the signature value to the challenger. Finally, the challenger uses the public key associated with the challenged party's AID account to verify the signature value, thereby confirming the identity of the challenged party. It is important to note that this process requires two rounds, meaning each participant must take turns acting as both the challenger and the challenged.

[0046] In addition to the standard verification process described above, depending on the specific needs of certain scenarios, the AID account verification process may also involve verifying the identity documents of another party, making the AID account verification process extremely cumbersome. This is especially true when a user holds multiple AID accounts, requiring them to perform a challenge / response for each account, resulting in a poor user experience. Furthermore, entering lengthy OOBI addresses is not user-friendly, as input errors are highly likely during the AID account verification process, leading to verification failures.

[0047] (2) Data silo problem in vLEI: Within the vLEI system, multiple QVI organizations exist, and AID users can choose to register their AID accounts with different QVI organizations. Since each QVI is only responsible for maintaining the information of its own registered users and does not communicate with other QVIs, this leads to the problem of duplicate user authentication. Furthermore, it further exacerbates the challenges users face when using digital identities, such as difficulties with cross-organization and cross-chain communication.

[0048] Furthermore, in terms of security, the alias management technologies in related fields are insufficiently secure and may face forgery risks. Some systems suffer from inadequate alias binding verification mechanisms, leading to malicious alias registration or tampering, causing users to question the credibility of aliases. Regarding scalability and interoperability, the alias management technologies in related fields have limitations in scalability and interoperability, and are insufficient in cross-chain compatibility. Especially in multi-chain environments, alias management is highly complex and carries the risk of uniqueness conflicts, further limiting the expansion of the blockchain and distributed digital identity ecosystem. In addition, the alias management technologies in related fields suffer from rigid user experience and functionality: the static binding mechanism of current identifier alias systems has limitations. Once bound, it is difficult to adjust or dynamically update (including transfer operations), failing to effectively address practical needs such as account permission changes or multi-account address management. At the same time, the cumbersome registration, verification, and transfer processes further limit user operational flexibility. Moreover, publicly disclosed alias binding relationships can easily raise user concerns about privacy leaks.

[0049] Based on the above analysis, distributed digital identity (DID) technologies, especially user identity information management schemes based on the KERI / vLEI system, suffer from the following technical problems: The AID account verification process is complex and the user experience is poor: In the vLEI system, when two users holding AID accounts establish a connection, they need to perform a cumbersome "challenge / response" process (including exchanging OOBI addresses, video conferencing, signature verification, etc.). The process is complex and prone to errors, especially when users hold multiple AID accounts, resulting in a very poor user experience.

[0050] Cross-domain interoperability and data silo issues: There are multiple QVI organizations in the vLEI system. Each organization only maintains its own users' AID account information, which requires users to verify their identities repeatedly across different QVIs, forming data silos and making it difficult to achieve cross-organization and cross-chain identity recognition and collaboration.

[0051] The security and dynamic management capabilities of alias management systems are insufficient: Blockchain / DID alias systems have security risks (such as malicious registration and alias tampering), and most of them adopt a static binding mechanism, which is difficult to adjust or dynamically update once bound, and cannot flexibly cope with actual needs such as account permission changes and multi-account management.

[0052] The dilemma of balancing identity verification and privacy protection: verifying user identity often requires disclosing too much information, posing a risk of privacy breaches; while completely anonymous solutions cannot meet business compliance requirements (such as KYC). Achieving efficient and reliable identity verification while minimizing disclosure is a major technical challenge.

[0053] In view of this, embodiments of this application propose a distributed digital identity account processing method, apparatus, and electronic device to solve at least one of the above-mentioned technical problems.

[0054] Specifically, in the scheme proposed in this application embodiment, an authoritative centralized / semi-centralized platform—an alias management platform—is used to handle user alias registration and management. This alias management platform is operated by a trusted third party and serves as the trust anchor and core management node of the entire system. For example, the alias management platform could be a Certificate Authority (CA), an authoritative third-party organization responsible for issuing and managing digital certificates. The alias management platform verifies the identity of users (individuals or legal entities). After successful verification, at least a user account tree is created, containing at least one pair of leaf nodes. Each pair of leaf nodes records a distributed digital identity account (e.g., AID or DID account) and its associated information (QVI name, creation time, account type, OOBI, account serial number, etc.). Optionally, a user identity tree can also be created, using the user's various identity attributes (name, ID number, etc.) as leaf nodes to obtain another Merkle tree. Then, based on the user's settings, a globally unique, human-readable alias is determined and bound to multiple distributed digital identity accounts managed by the user account tree, or to multiple identity attribute information managed by the user identity tree. Next, the alias management platform issues a digital certificate as an identity credential for the user. The certificate contains the user's alias, and combines the root hash signature value of the user identity tree, the root hash signature value of the user account tree, and the hash value of the identity credential into an association record. This association record is stored in the alias registration database and simultaneously notarized on the blockchain, forming immutable evidence. When user information needs to be verified, the verifier (such as QVI or other users) initiates a query request to the alias management platform. Based on the user's query request, the alias management platform generates a zero-knowledge proof (Merkle Proof) for specific information from the Merkle tree. The verifier can confirm the authenticity of the user information by comparing the root hash value calculated based on the zero-knowledge proof with the publicly available association record on the blockchain, without obtaining all of the user's private data, thus simplifying the verification process.

[0055] This method can be applied to one or more practical application scenarios, such as IoT device identity management, healthcare, digital government and public services, cross-border transactions, supply chain transactions, and enterprise digital identity management. For example, in a supply chain transaction scenario, it can be used to verify the identity of multi-level suppliers. A core manufacturing enterprise (such as an automobile factory) needs to collaborate with hundreds of upstream and downstream suppliers, involving contract signing, order confirmation, invoice circulation, and other processes. Each supplier may register different distributed digital identity accounts (such as AID accounts) on different QVIs. The core manufacturing enterprise needs to verify the identity of each supplier and the authenticity of the authorized representative's identity one by one. The verification process is time-consuming and affects the efficiency of the supply chain. Using the solution proposed in this application, when the legal director of supplier A needs to sign a contract, the core enterprise only needs to receive the alias of supplier A (such as @SupplierA:LegalHead), query the alias management platform, verify its identity and authorized role, and confirm its right to sign the contract through zero-knowledge proof.

[0056] like Figure 1 As shown in the embodiments of this application, the distributed digital identity account processing method can be applied to an alias management platform, and may specifically include the following process: Step 101: The alias management platform receives the alias registration request for the first user sent by the first QVI organization.

[0057] Before step 101, the first user registers a first account with the first QVI organization. In this specification, unless otherwise specified, the account (e.g., the first account) is a distributed digital identity account. For example, the first account can be an AID account or a DID identifier. For the sake of brevity, the following description primarily uses an AID account as an example, meaning the first account is the first AID account. Based on the following description, the AID account can be replaced with other distributed digital identity accounts to obtain various other embodiments.

[0058] Subsequently, the first QVI organization triggers the alias registration process. The first QVI organization sends an alias registration request to the alias management platform, carrying the first AID account association information and the first user's primary identity information. The first AID account association information includes the first AID account and the associated information corresponding to it. This associated information may include the QVI organization name, creation time, account type, OOBI, etc. For example, the primary associated information corresponding to the first AID account includes the first QVI organization name, the creation time of the first AID account, the account type of the first AID account, and the OOBI of the first AID account.

[0059] Step 102: Create a user account tree based on the first AID account association information corresponding to the first user carried in the alias registration request.

[0060] In some embodiments, after receiving an alias registration request for a first user from a first QVI organization, the alias management platform first performs KYC (Know Your Customer) authentication on the first user. KYC authentication may specifically include: verifying the authenticity and accuracy of the first user's identity materials, and then further verifying the authenticity of the first user's identity by sending a verification code to the first user's email, mobile phone, or other terminal device / application, or by using biometric identification (such as facial recognition or fingerprint recognition). If any of the above verifications fails, an error message is returned to the first QVI organization. If all verifications pass, the alias management platform searches for user information matching the first user's identity materials in the alias registration database maintained by the alias management platform. The user information may be one or more of at least one attribute information included in the identity materials. If no user information matching the first user's identity materials is found, it is assumed that the first user has not yet registered an alias, and the alias management platform creates a user account tree for the first user.

[0061] A user account tree is a Merkle tree that includes one or more pairs of leaf nodes.

[0062] A Merkle tree (MT) is a hash binary tree that forms a tree structure by hashing a large number of data fragments. The root node (Merkle root) represents the entire content of all the underlying data. For example... Figure 2 As shown, Figure 2 A concrete example of a Merkle tree is shown. Let D = {D1,...D8} represent a dataset, and assume the hash function Hash() is publicly known. In this Merkle tree example, N8,...,N15 are leaf nodes of the Merkle tree, N1,...,N7 are non-leaf nodes, and N1 is the root node; D1,...,D8 and the dashed lines connecting them are only to illustrate their association with the leaf nodes and do not belong to the Merkle tree itself. Each leaf node value is obtained by calculating the hash value of its corresponding data; for example, N8 = Hash(D1). Each non-leaf node value is obtained by concatenating the hash values ​​of its left and right child nodes and then calculating the hash again. For example, N3 = Hash(Hash(N6) + Hash(N7)), N1 = Hash(Hash(N2) + Hash(N3)).

[0063] Initially, the user account tree consists of only one pair of leaf nodes (defined as the first pair of leaf nodes) to record the first AID account association information. The first AID account association information includes the first AID account and the first association information. One node in the first pair of leaf nodes records the AID account, and the other leaf node records the first association information. For example, a user account tree consisting of only one pair of leaf nodes would look like this: Figure 3 As shown, N1 represents the root node, and N2 and N3 represent a pair of leaf nodes.

[0064] It's important to note that each user corresponds to a user account tree, which can include multiple pairs of leaf nodes to manage multiple AID accounts held by the same user. Each pair of leaf nodes records the AID account and its associated information. The alias management platform can sequentially number multiple AID accounts under the same user (same alias) and add the AID number to the associated information recorded in the leaf nodes. The AID number is generated by the alias management platform based on the total number of AID accounts held by the same user (including those previously held). The AID number represents the sequence number of the corresponding AID account among the multiple AID accounts held by the same user (e.g., the first user). Furthermore, this AID number is strictly incremental, ensuring the uniqueness of each user's AID number.

[0065] In some embodiments, optionally, in addition to creating a user account tree, a user identity tree is also created. Based on at least one identity attribute information (e.g., name, date of birth, ID number, etc.) contained in the first user's first identity material information carried in the alias registration request, a Merkle tree storing user identity information is constructed according to the binary Merkle tree generation method described above, referred to as the user identity tree. Each leaf node of the user identity tree corresponds one-to-one with each type of user identity attribute information, and the value of each leaf node is a hash value generated by hashing its corresponding identity attribute information. For example, an example of a user identity tree is shown below. Figure 4 As shown.

[0066] Step 103: Determine the first unique alias corresponding to the first user, bind the first alias to the user account tree, and generate the first identity credential.

[0067] The method for determining a globally unique alias for the first user can be as follows: the alias management platform sends a request to the first QVI organization to retrieve the first user's alias. The first QVI organization either retrieves the alias set by the first user beforehand or retrieves the alias set by the first user in response to the request. The first QVI organization then returns the alias set by the user to the alias management platform. The alias management platform queries the alias registration database based on the alias set by the user to determine if the alias is globally unique. If the alias has already been registered by another user, the platform resends the request to the first QVI organization to retrieve the user's alias, continuing until the alias set by the user has not been registered, and then proceeds to the next steps.

[0068] Next, the alias management platform can bind at least the first alias to the user account tree and store the binding relationship in the alias registration database. In some embodiments, the first alias is bound to the first identity material information, the first AID account, the user account tree, and the user identity tree, and the binding relationship is stored in the alias registration database. The alias management platform generates a first identity credential for the first user, and the extended domain of the first identity credential includes the first alias.

[0069] Step 104: Combine at least the hash signature value of the first root of the user account tree and the hash value of the first identity credential to generate the first associated record.

[0070] The first hash signature value of the user account tree can be obtained as follows: Based on the structure of the created user account tree and the values ​​recorded in each leaf node, calculate the hash value of the root node level by level, and then use the private key held by the alias management platform, for example, if the alias management platform is a CA institution, use the CA private key held by the CA institution to sign the root hash value of the user account tree to obtain the first hash signature value of the user account tree.

[0071] In some embodiments, instead of generating a user identity tree, only a user account tree may be generated. In this case, the first associated record is obtained by combining the hash signature value of the first root of the user account tree and the hash value of the first identity credential. In other embodiments, a user identity tree may be generated. In this case, the first associated record is obtained by combining the hash signature value of the first root of the user account tree, the root hash signature value of the user identity tree, and the hash value of the first identity credential.

[0072] The root hash signature value of the user identity tree is obtained by calculating the hash value of the root node level by level based on the structure of the created user identity tree and the values ​​recorded in each leaf node. Then, the root hash value of the user identity tree is signed using the private key held by the alias management platform, such as a CA institution.

[0073] The hash value of the first identity credential is the hash value obtained by performing a hash calculation on the first identity credential using a publicly available hash algorithm.

[0074] Step 105: Synchronously store the first associated record on the blockchain.

[0075] The first associated record is synchronously stored on the blockchain, which means publishing the first associated record to the blockchain, making the first associated record public and tamper-proof.

[0076] After the first association record is synchronously stored on the blockchain, the alias management platform returns the query address of the first association record on the blockchain to the first QVI institution. The first QVI can then query the first association record using this address.

[0077] Step 106: In response to receiving the query request submitted by the second user, determine the corresponding user account tree based on the alias to be verified carried in the verification request, and generate a zero-knowledge proof based on the user account tree.

[0078] The second user is the verifier, the first user is the verified party, and the alias management platform is the prover. The second user can be a QVI organization or other type of entity, or a user of the same type as the first user, such as an individual user.

[0079] In step 103, the alias and user account tree have been bound and stored in the alias registry. Therefore, based on the alias to be verified carried in the query request, the registry can be checked to see if the alias has already been registered. If it has, then a corresponding user account tree must exist. Then, based on the user account tree, a corresponding zero-knowledge proof is generated.

[0080] In this embodiment of the application, the zero-knowledge proof generated based on the user account tree specifically includes the hash value of the sibling node in the Merkle path from the leaf node to the root node of an AID account corresponding to the verified user (e.g., the first user) and the data plaintext (e.g., the plaintext of the AID account) or the hash value of the data plaintext of the leaf node corresponding to the AID account.

[0081] When a prover (such as the first user or an alias management platform) needs to prove the authenticity of an alias, they can provide the path to the data (called the Merkle path) and the Merkle root. The verifier verifies that the data indeed belongs to the overall dataset represented by the Merkle root by calculating the hash values ​​in the path level by level, without accessing or disclosing all the underlying data. Using this structure, zero-knowledge proofs can efficiently and securely verify the existence or correctness of data while ensuring data privacy is not compromised.

[0082] Step 107: Return the first account, zero-knowledge proof, and first identity credential to the second user to trigger the second user to verify the first account held by the first user based on the zero-knowledge proof and the first association record queried from the blockchain.

[0083] In step 105, the alias management platform has already combined the hash value of the first user's first identity credential and the root node hash signature value of the user account tree (i.e., the root hash signature value) into a first association record and stored it in the blockchain. In other embodiments, the hash value of the first user's first identity credential, the root node hash signature value of the user account tree (i.e., the root hash signature value), and the root hash signature value of the user identity tree are combined to form a first association record and stored in the blockchain.

[0084] If the alias management platform wants to prove that the first account (e.g., the first AID account) of the first user returned to the second user is real, it needs to return the following data to the second user: the first user's identity credentials, the first user's AID account obtained from the query and the zero-knowledge proof corresponding to the first user's associated account tree.

[0085] After receiving the data returned by the alias management platform, the second user verifies the correctness of the first AID account and the zero-knowledge proof. Subsequently, by combining the first association record obtained from the blockchain and the public key information of the alias management platform, the user account tree is verified and confirmed to be unaltered and to be associated with the first identity credential (which contains the alias in the extended domain).

[0086] To better understand how to perform verification using zero-knowledge proofs based on Merkle trees, please refer again. Figure 2 In the Merkle tree example shown, the prover needs to provide the sibling nodes of all nodes traversed on the path from the leaf node to the root node. For example, first determine the data D3 corresponding to the alias, such as data D3 specifically being the first AID account, and then prove that the first AID account belongs to set D. The prover then performs the following steps: Find the Merkel path of the leaf node corresponding to data D3 and all its contained nodes, namely N10, N5, N2 and N1; find the sibling nodes of all nodes in the Merkel path, namely N11, N4 and N3; provide the verifier with data D3 (e.g., the first AID account), as well as the hash values ​​of nodes N11, N4 and N3, as a zero-knowledge proof. That is, the zero-knowledge proof includes data D3, as well as N11, N4 and N3, without providing any additional information.

[0087] After receiving the zero-knowledge proof from the alias management platform (the prover), the verifier (e.g., the second user) calculates the hash value N10' based on D3 (the first AID account) sent by the prover, i.e., N10' = Hash(D3). Based on N10' calculated in the previous step and N11 sent by the prover, N5' is calculated, i.e., N5' = Hash(Hash(N10') + Hash(N11)). Based on N5' calculated in the previous step and N4 sent by the prover, N2' is calculated, i.e., N2' = Hash(Hash(N5') + Hash(N4)). Based on N2' calculated in the previous step and N3 sent by the prover, N1' is calculated, i.e., N1' = Hash(Hash(N2') + Hash(N3)). During this process, the verifier cannot know any information about the other data in D besides D3.

[0088] In some embodiments, as a possible implementation, the verifier (e.g., a second user) can first obtain the public key information of the alias management platform. For example, the alias management platform can publish the public key information to the blockchain, and the verifier can obtain the public key information of the alias management platform through blockchain query. This public key information and the aforementioned CA private key constitute a key pair, which is generated based on an asymmetric encryption algorithm.

[0089] The public key information is used to verify the root hash signature value S of the user account tree recorded on the blockchain. The verification process requires the following elements: CA public key, root hash signature value S (obtained from the blockchain), and the calculated root hash value N1' (the original message before CA private key signing). The root hash signature value S of the user account tree retrieved from the blockchain is verified to obtain the verification result. If the verification result indicates that the verification is successful, it means that the user account tree has not been tampered with and the first AID account is genuine. Furthermore, the verifier calculates the hash value of the first identity credential and verifies the correlation between the calculated hash value of the first identity credential and the root hash signature value S by checking the first associated record retrieved on the blockchain. This also proves the authenticity of the first identity credential.

[0090] It should be noted that the verifier (second user) and the alias management platform (prover) need to use the same hash function.

[0091] In this embodiment of the application, the root hash signature value of the user account tree can be obtained from the first associated record in the blockchain, and the root hash signature value of the user account tree is obtained by signing with the private key held by the alias management platform.

[0092] In other embodiments, as another possible implementation, the alias management platform can publish the root hash value N1 of the user account tree to the blockchain. The verifier can directly query the root hash value N1 of the user account tree on the blockchain, compare the calculated N1' with N1, and if they match, it is considered that the first AID account does indeed belong to the user account tree and has not been tampered with.

[0093] Figure 1 The illustrated embodiment, based on an alias management platform, achieves centralized management and notarization of user identity information (user identity tree) and multiple account information (user account tree). The verifier (QVI institution or user) only needs to know the user's alias to query and verify the user's identity and all accounts under that name through the alias management platform, regardless of which QVI these accounts were registered on or which blockchain they are based on. This completely breaks down data silos between QVIs, achieving a unified identity view across institutions and blockchains. Furthermore, this method simplifies the verification process and improves user experience: it reduces multi-round, complex interactive verification to a one-time on-chain notarization query. The first user only needs to tell the second user "My alias is XXX," and the second user can obtain the zero-knowledge proof of the specified account under the first user's name through the alias management platform and compare it with the notarization record on the blockchain. This completely replaces the cumbersome process of exchanging OOBIs, video conferencing, and multi-round signature verification, transforming the verification process from "interactive" to "query-based," significantly improving efficiency and user experience.

[0094] The above-mentioned solution proposed in this application embodiment can also improve the security and dynamic management capabilities of the alias system: aliases are assigned by authoritative CA institutions after strict KYC verification and are solidified through blockchain notarization, thus preventing malicious registration and alias tampering from the source. The dual Merkle tree structure and on-chain notarization ensure the integrity, authenticity, and immutability of all user identity and account information.

[0095] Dynamic management capabilities: Merkle trees support efficient dynamic updates. When a user adds or deletes an account or updates their identity information, only the corresponding user account tree or user identity tree needs to be updated, and a new associated record is generated and uploaded to the blockchain. The entire process allows users to flexibly change aliases and add, delete, modify, and query accounts under their name, solving the problem of static binding.

[0096] The proposed solution in this application also balances identity verification and privacy protection: zero-knowledge proofs play a crucial role. The verifier only needs to see the Merkel path proof of the verified information to be certain that the information belongs to a dataset signed by an authoritative platform and stored on the blockchain, without needing to know the user's name, all accounts, or any other sensitive information. For example, when QVI issues vLEI credentials, it only needs to verify the user's "name" or other single attribute information to confirm its authenticity through zero-knowledge proofs, without needing to view all of the user's KYC materials. This perfectly achieves the "minimum disclosure" principle, maximizing the protection of user privacy while meeting KYC compliance requirements.

[0097] The following are some specific examples.

[0098] In one specific embodiment, a first user selects a first QVI organization and submits identity information (including at least one identity attribute such as name, date of birth, and ID number) to apply for a new AID account with that QVI organization. The first QVI organization first verifies the user's identity information, such as whether the ID number is accurate, whether the ID number matches the name, and whether the date of birth matches the date of birth on the ID number. Then, it further verifies the authenticity of the first user's identity by sending a verification code or using biometric identification. If any of the above verifications fails, the user's registration process is terminated, and the review and verification results are returned to the user. If all verifications pass, the first QVI organization creates a new AID account for the user (the password for this account is managed by the first QVI organization), and then generates an alias registration request and sends it to the alias management platform. The alias registration request carries the identity information submitted by the first user and the AID account association information (including the AID account and association information, including OOBI, account type, etc.). The alias management platform is operated by a CA organization, which holds the CA private key.

[0099] After receiving an alias registration request from the first QVI organization, the alias management platform first verifies the first user's identity information. Then, it further verifies the user's authenticity through methods such as sending a verification code or biometric identification. If any of these verifications fails, an error message is returned to QVI. If all verifications pass, the platform searches for user information matching the identity information in its alias registration database. If the search results show a matching user, an update process is executed; otherwise, if no matching user is found, a registration and creation process is executed.

[0100] If no matching user information is found in the alias registration database, it is determined that the user has not yet registered on the platform. Figure 5 As shown, perform the following registration and creation process: Step 501: The alias management platform sends a request to the first QVI organization to obtain the user's alias and retrieves the alias set by the user.

[0101] For example, the first QVI organization first obtains the aliases set by the users from the users, and then returns them to the alias management platform.

[0102] Step 502: The alias management platform searches the alias registration database based on the aliases set by the user.

[0103] If the alias has already been registered by another user, the request to obtain the user alias is resent to the first QVI organization (i.e., jump back to step 501 to execute); if the alias has not been registered, the following steps continue to be executed.

[0104] Step 503: Create a user identity tree based on the first user's first identity material information.

[0105] For example, following the binary Merkle tree generation method described above, a Merkle tree storing user identity information can be constructed, referred to simply as a user identity tree. Each leaf node in the user identity tree corresponds one-to-one with each identity attribute of the user, and the value of each leaf node is generated by hashing its corresponding user attribute value. For example, refer to... Figure 4 The example shown has a user identity tree with 15 nodes, where N1 is the root node, N1-N7 are non-leaf nodes, and N8-N15 are leaf nodes, corresponding to the user's identity attributes such as name, date of birth, ID number, phone number, and address.

[0106] Step 504: Create a user account tree based on the first AID account association information carried in the alias registration request sent by the first QVI organization.

[0107] Construct a Merkle tree to store user account association information, referred to as the user account tree. The initially created user account tree contains only two leaf nodes. One leaf node corresponds to the first user's first AID account, represented as a string, for example, "Ei5csblWpTy22uVkbZrZxvSUORxPvIlrfpq2e1hKTtfA". The other leaf node corresponds to the account information associated with the first AID account, defined as the first association information. For example, it can be expressed as a JSON string, and internally includes specified information according to the alias management platform's preset standards. The association information may specifically include QVI organization name, creation time, account type, OOBI, AID serial number, etc. An example of association information is given below: { “QVI”: “CFCA”, "TIME": "202511221501", "TYPE": "single" "OOBI": ["http: / / www.oobi1.com:5641 / oobi / Ei5csblWpTy22uVkbZrZxvSUORxPvIlrfpq2e1hKTtfA", "http: / / www.oobi2.com:5641 / oobi / Ei5csblWpTy22uVkbZrZxvSUORxPvIlrfpq2e1hKTtfA"], “INDEX”: “1” } In the example of the above associated information, QVI is the name field, and "CFCA" represents the name of the first QVI organization. TIME is the creation time field, and 202511221501 indicates the time when the first AID account was registered on the alias management platform. TYPE is the type field, and single indicates that the first account belongs to the single type. Account types include single or multi, indicating whether the account is held by a single user or multiple users, respectively. The data following the OOBI field ["http: / / www.oobi1.com……2e1hKTtfA"] represents an array of OOBI addresses associated with the first account, and INDEX is the sequence number field, representing the unique sequence number of the first AID account among all the multiple AID accounts held by the user.

[0108] For example, refer to Figure 6 , Figure 6 A specific example of a user account tree is given. The user account tree contains 15 nodes, where N1 is the root node, N1-N7 are non-leaf nodes, and N8-N15 are leaf nodes, corresponding to a total of 4 sets of AIDs and associated account information. Figure 6 The associated account information 1 to associated account information 4 associated with the middle leaf node all represent associated information, and AID1 to AID4 represent AID accounts.

[0109] Step 505: Generate a digital certificate for the first user as an identity credential to prove the user's identity.

[0110] The extended field of the identity credential contains the user's alias information.

[0111] Step 506: Combine the first root hash signature value of the user account tree, the root hash signature value of the user identity tree, and the hash value of the identity credential to generate the first association record. Store the first association record in the alias registration database and simultaneously deposit it into the blockchain.

[0112] Specifically, the root node hash values ​​of the user identity tree and the user account tree are signed using the private key of the alias management platform to obtain the first root hash signature value of the user account tree and the root hash signature value of the user identity tree. The identity credential is then hashed to obtain its hash value. These three are then linked to generate the corresponding first association record.

[0113] Step 507: Return the identity certificate and the query address of the first associated record on the blockchain to the first QVI institution.

[0114] Step 508: The second user sends a request to the first user to obtain the information to be verified.

[0115] The information to be verified may include the AID account held by the first user.

[0116] Step 509: The first user sends the information to be verified (first alias and optional additional information) to the second user.

[0117] In response to the retrieval request in step 508, the first user can return only the alias. Optionally, in some embodiments, the alias plus additional information can also be returned. The additional information may include at least one of the following: the name / code of the QVI organization, the account creation time, the account type, and the account serial number.

[0118] For example, the additional information could be the AID account's serial number, i.e., the index in the example above, representing the AID account's serial number among the first user's multiple AID accounts. For instance, in one embodiment, the verification information returned by the first user is "@SupplierA:LegalHead", while in other embodiments, the verification information returned by the first user is "@SupplierA:LegalHead, index:1", where @SupplierA:LegalHead represents the first alias, and index:1 indicates that the AID account's serial number is 1.

[0119] For example, additional information could be the name of the QVI organization or its code. Or, for example, additional information could be the creation time of the AID account or the type of AID account.

[0120] Step 510: After receiving the verification information sent by the first user, the second user initiates a structured query request to the alias management platform.

[0121] Structured query requests carry information to be verified. For example, aliases and additional information constitute the structured query conditions.

[0122] Step 511: The alias management platform queries the alias registration database based on the structured query request of the second user.

[0123] Step 512: If no alias record that satisfies the structured query request is found, the alias management platform returns a "alias does not exist" message to the second user.

[0124] Step 513: If an alias record that satisfies the structured query request is found, the alias management platform determines the corresponding target AID account based on the alias in the structured query request.

[0125] Specifically, the alias management platform determines the corresponding target AID account based on the alias in the structured query request. This determination can be done in different ways depending on whether optional additional information is provided in the structured query request.

[0126] If no additional information is provided, a default account is selected. No additional information is provided, meaning the structured query request issued in step 511 only contains the alias of the first user and no additional information. In this embodiment, users holding multiple AID accounts can set a default account on the alias management platform. If a user holds multiple AID accounts (at least two), the user must select a default account and submit that information to the alias management platform.

[0127] If no additional information is provided in the structured query request (hereinafter referred to as the query request), the alias management platform will determine the target AID account corresponding to the first alias of the first user as the default account pre-set by the first user. This method can simplify the alias query process, improve query execution efficiency, and enhance user experience.

[0128] If additional information has been provided, and multiple AID accounts match the provided information, then one AID account will be randomly selected from the multiple AID accounts held by the first user that meet the structured query criteria, and this AID account will be used as the target AID account. For example, if the same user can register multiple AID accounts with the same QVI organization, and the additional information includes the name of the first QVI organization, then one of the multiple AID accounts registered by the first user with the first QVI organization can be randomly selected as the target AID account. Alternatively, if a user creates multiple AID accounts at the same time, and the additional information includes the creation time (e.g., the creation time is in days as the smallest query unit), then one of the multiple AID accounts created on the same day can be randomly selected as the target AID account.

[0129] Step 514: Determine the corresponding user account tree based on the alias to be verified carried in the query request, and generate a zero-knowledge proof based on the user account tree and the target AID account.

[0130] Zero-knowledge proofs include the plaintext or hash value of the target AID account, as well as the hash values ​​of the multiple sibling nodes included in the path from the target AID account to the root node.

[0131] Step 515: The alias management platform returns the first identity credential, the target AID account, the associated information corresponding to the target AID account (defined as target associated information), and the zero-knowledge proof to the second user.

[0132] It should be noted that the returned zero-knowledge proofs include both the zero-knowledge proof corresponding to the target AID account and the zero-knowledge proof corresponding to the target associated information. For example, combining... Figure 6 As shown, assuming the target AID account is AID3, the corresponding target associated information is associated account information 3. The zero-knowledge proof corresponding to the target AID account AID3 includes the hash values ​​of node N13 (optional), node N12 (optional), node N7, and node N2. The zero-knowledge proof corresponding to the target associated information (associated account information 3) includes the hash values ​​of node N13 (optional), node N12 (optional), node N7, and node N2. From... Figure 6 As can be seen, since the target AID account and its corresponding target association information are recorded in a pair of leaf nodes, the paths from these leaf nodes to the root node are basically consistent. The sibling nodes corresponding to the Merkel paths from the leaf nodes to the root node are also essentially the same; for example, they all include sibling nodes N7 and N2. In step 515, since the plaintext of the target AID account and target association information is returned together, and assuming the verifier and alias management platform use the same hash function, the returned zero-knowledge proof is simplified and can include only the hash values ​​of node N7 and node N2. The hash values ​​of nodes N12 and N13 can be obtained by the verifier hashing the plaintext, thus making them optional in the zero-knowledge proof.

[0133] Step 516: The second user verifies the authenticity of the first user's identity by combining the first association record publicly available on the blockchain with the first identity credential and zero-knowledge proof provided by the alias management platform.

[0134] The second user verifies the first user's identity information and performs zero-knowledge proof to confirm the authenticity of the first user's identity and account ownership information. If the verification is successful, the second user then accesses the OOBI address contained in the first user's account information to obtain the key event associated with that account and completes its parsing.

[0135] Specifically, zero-knowledge proofs include the hash value or plaintext of the target AID account, and the hash values ​​of multiple sibling nodes corresponding to the path from the leaf node to the root node corresponding to the target AID account, for example, Figure 6 In the user account tree example shown, assuming the sequence number in the additional information is 1, then AID1 is the target AID account. The zero-knowledge proof includes: the plaintext or hash value of AID1, and the associated information recorded in node N8 (i.e., Figure 6 The hash values ​​of associated account information 1), node N5, and node N3 are shown in the figure.

[0136] The second user uses zero-knowledge proofs to calculate the hash value of the root node of the user account tree and retrieves the CA public key of the alias management platform from the blockchain.

[0137] The second user obtains the query address of the first associated record on the blockchain. For example, the second user requests it from the first QVI institution. Based on the query address of the first associated record, the second user queries the first associated record on the blockchain and reads the root hash signature value (S) of the user account tree from the first associated record.

[0138] In the private key signing and public key verification process based on asymmetric encryption algorithms, public key verification requires three elements: the root hash value (M) to be signed, the root hash signature value S, and the CA public key. The calculated root node hash value of the user account tree is used to replace the hash (root hash value) to perform public key verification. The verification operation is: result = verify(M, S, CA public key). If result is true, it means that the calculated root node hash value is consistent with the root node hash value before the private key signing, proving that the information to be verified provided by the first user is true.

[0139] If a matching user information is found in the alias registration database, it means that the platform has already saved the user identity tree and user account tree associated with that user. At this point, the platform only needs to update the user account tree associated with that user to complete the addition of the new account.

[0140] For example, the second QVI organization sends an alias registration request for the first user to the alias management platform. The alias management platform recognizes that the user has already registered, so it creates a pair of new leaf nodes in the existing user account tree, corresponding to the AID account and its associated information of the newly created account. Then, it inserts the newly created leaf node pair into the user account tree and updates the non-leaf nodes inside the binary tree simultaneously.

[0141] It should be noted that this application embodiment does not restrict the binary tree update algorithm used, but it must ensure that the addresses and account information stored in each pair of sibling leaf nodes are related. For example, the leaf node corresponding to AID1 and associated account information 1 is a sibling node, and the leaf node corresponding to AID2 and associated account information 2 is a sibling node. Subsequently, the alias management platform uses its private key to sign the hash value of the root node of the updated user account tree, and combines it with the signature value of the root node of the user identity tree and the hash value of the user credential to generate a new set of associated records, which are stored in the alias registration database and simultaneously notarized on the blockchain. Finally, the alias management platform returns the query address of the new associated record on the chain to the second QVI institution. The second QVI institution returns a notification message to the user indicating that the AID account has been successfully created.

[0142] Specifically, such as Figure 7 As shown, in some embodiments, the process for updating the user account tree is as follows: Step 701: In response to receiving the alias registration request for the first user from the second QVI organization, and if it is determined from the first identity information that the first user has already registered the first alias, create a second pair of leaf nodes in the user account tree corresponding to the first user.

[0143] The second pair of leaf nodes is used to record the second AID account association information; the second AID account association information includes the second AID account registered by the first user at the second QVI institution.

[0144] For example Figure 6 The AID2 shown is the second AID account.

[0145] Step 702: Bind the first AID account, the second AID account, and the first alias.

[0146] Step 703: After creating the second pair of leaf nodes, redetermine the second root hash signature value of the user account tree.

[0147] The second root hash signature value of the user account tree is determined by recalculating the root hash value of the user account tree and signing the root hash value of the user account tree with the CA private key to obtain the second root hash signature value.

[0148] Step 704: Combine the root hash signature value of the user identity tree, the second root hash signature value of the user account tree, and the hash value of the first identity credential to generate the second associated record.

[0149] Step 705: Synchronously store the second associated record on the blockchain.

[0150] Step 706: Return the query address of the second associated record on the blockchain to the second QVI institution.

[0151] In some embodiments, the method proposed in this application can also be used for user identity information management. In practical applications, when an AID user (natural person, legal person, etc.) holding an AID account wishes to update their identity information, they can first submit an application and attach updated identity materials to a QVI organization hosting their AID account (i.e., the user must have registered an AID account with that QVI). The QVI organization will then verify the updated identity materials and the authenticity of the subject. Subsequently, the alias management platform will again verify the identity materials and the authenticity of the subject. After verification, the alias management platform will update the user identity tree associated with the user. Each leaf node of the updated user identity tree still maintains a one-to-one correspondence with each identity attribute of the user (each leaf node actually stores the hash value of the user attribute value). The execution process is similar to the registration of a new AID account in AID account management, and may include, for example, the following steps: A binary tree update algorithm is selected (this application embodiment does not limit the binary tree update algorithm); the user identity tree is updated based on the user's identity information; the alias management platform uses its platform private key (CA private key) to sign the hash value of the root node of the updated user identity tree, and then combines it with the hash signature value of the root node of the user account tree and the hash value of the user identity credential to generate a new association record (fourth association record), which is then stored in the alias registration database and simultaneously notarized on the blockchain, and the query address of the new association record on the chain is returned to QVI. When the QVI institution receives the new query address sent by the alias management platform, it then returns a prompt message to the user indicating that the identity information update is successful.

[0152] Specifically, such as Figure 8 As shown, the user identity information update process can be implemented through the following steps: Step 801: In response to receiving the identity information update request for the first user sent by the first QVI organization, the alias management platform verifies the updated second identity material information carried in the identity information update request and the authenticity of the first user. If the verification is successful, the identity attribute information recorded in the corresponding leaf node in the user identity tree is updated.

[0153] Step 802: The alias management platform determines the root hash signature value of the updated user identity tree.

[0154] Step 803: The alias management platform combines the updated root hash signature value of the user identity tree, the root hash signature value of the user account tree, and the hash value of the first identity credential to generate the fourth association record.

[0155] Step 804: The alias management platform will synchronously store the fourth association record on the blockchain.

[0156] Step 805: The alias management platform returns the query address of the fourth associated record on the blockchain to the first QVI institution.

[0157] In some embodiments, the method proposed in this application also supports user alias replacement.

[0158] If an AID account holder (individual or legal entity) wishes to change their username, they can first submit a username change application to a QVI (Quality Management Entity) that manages their AID account, along with the new username information. The QVI will then forward the request to the username management platform, which will verify the user's identity, change the username, and reissue identity credentials. For example, the specific process might be: the AID user (individual or legal entity) applies to the QVI to change their username, along with the new username information. The QVI then sends the application materials to the username management platform. The username management platform sends a dynamic verification code to the user's email or mobile phone, or collects the user's facial image, to verify the user's identity. The alias management platform checks the alias registry to see if the new alias has already been registered. If it has, it sends a request to QVI to retrieve the new alias. If the alias has not been registered, it registers it in the alias registry, revokes the user's associated identity credentials, and deletes the replaced alias information. Next, the alias management platform generates a new digital certificate for the user as their new identity credential. The extended field of this certificate contains the changed user alias information. Then, it calculates the hash value of the new user identity credential (second identity credential), combines it with the root node signature values ​​of the user identity tree and user account tree to generate a new association record (fifth association record), and stores it in the alias registry, simultaneously notating it on the blockchain. It returns the query address for the identity credential and the on-chain association record to QVI. QVI then returns a notification message to the user indicating that the alias change was successful.

[0159] Specifically, based on the above exemplary description, in some embodiments, such as Figure 9 As shown, the specific implementation process of alias update includes the following steps: Step 901: In response to receiving the alias update request for the first user sent by the first QVI organization, verify the first identity material information carried in the alias update request and the authenticity of the first user. If the verification is successful, query whether the second alias carried in the alias update request has been registered.

[0160] Step 902: If the second alias has already been registered, re-obtain the third alias corresponding to the first user.

[0161] Step 903: If the second alias has not been registered, generate a second identity credential.

[0162] The extended field of the second identity credential includes the second alias.

[0163] Step 904: Combine at least the root hash signature value of the user account tree and the hash value of the second identity credential to generate the fifth associated record.

[0164] In some embodiments, the root hash signature value of the user account tree and the hash value of the second identity credential are combined to generate the fifth association record. In another embodiment, the root hash signature value of the user account tree, the root hash signature value of the user identity tree, and the hash value of the second identity credential are combined to generate the fifth association record.

[0165] Step 905: Synchronously store the fifth associated record on the blockchain.

[0166] Step 906: Return the query address of the fifth associated record on the blockchain to the first QVI institution.

[0167] Depending on the needs of certain business scenarios, users may apply for vLEI credentials from different QVI organizations, even if the user has not registered an AID account with that organization. According to the relevant requirements for vLEI credential issuance, QVI organizations need to verify the user's identity and account information before issuing a vLEI credential to a user. The method proposed in this application embodiment can also be used to achieve rapid user identity verification when issuing vLEI credentials.

[0168] The following details how QVI (QVI for short) quickly completes the identity verification process for users based on user aliases, such as... Figure 10 As shown, the process of assisting QVI organizations in verifying user identity and account information before issuing vLEI credentials to users may specifically include the following steps: Step 1001: In response to receiving the authentication request for the first user sent by the third QVI organization, the alias management platform verifies the authenticity of the first user.

[0169] The authentication request is generated by a third QVI authority in response to a request from a first user to issue a vLEI credential. For example, the first user submits a request to the third QVI authority to obtain a vLEI credential, which includes the first user's alias and account number information. The account number information is the serial number of the AID account.

[0170] The third QVI organization receives the application request from the first user and determines the user identity attribute information required to generate the vLEI credential. This user identity attribute information includes at least one identity attribute from identity document information, such as ID number, name, date of birth, and telephone number. Based on the first user's alias, account number, and the first user's identity attribute information required to issue the vLEI credential, the third QVI organization obtains combined query conditions and initiates a structured query request (i.e., the identity verification request in step 1001) to the alias management platform. The structured query request carries the combined query conditions; that is, the identity verification request carries the alias, account number, and user identity attribute information required to issue the vLEI credential to be verified.

[0171] The alias management platform verifies the authenticity of the first user. Specifically, the alias management platform may first send a dynamic verification code to the first user's email or mobile phone, or collect the user's facial image, fingerprints, or other biometric features to complete the verification of the first user's identity.

[0172] Step 1002: If the verification is successful, check if the alias to be verified carried in the authentication request exists.

[0173] To check if the alias to be verified carried in the authentication request exists, you can query a specific database managed or maintained by the alias management platform, such as the aforementioned alias registration database. After the first user registers an alias, the alias can be bound to the first user's identity information, at least one AID account, user account tree, and user identity tree, and stored in the alias registration database. Then, you can query the specified database to check if the alias to be verified carried in the authentication request exists, i.e., whether the alias to be verified is a registered alias. The query results can be divided into two cases: If no alias matching the alias to be verified in the authentication request is found in the alias registry, or if no AID account bound to the alias to be verified is found, the alias management platform returns a "Account does not exist" message to the third-party QVI organization.

[0174] If an alias matching the alias to be verified in the authentication request is found in the alias registry, and / or an AID account bound to the alias to be verified is found, proceed to step 1003.

[0175] Step 1003: If the alias to be verified exists, determine the target AID account corresponding to the alias to be verified.

[0176] After finding the alias to be verified in the alias registry, based on the AID account sequence number information carried in the authentication request, the AID account with the corresponding sequence number is selected from multiple accounts bound to the alias to be verified as the target AID account corresponding to the alias to be verified. For example, such as Figure 6 As shown, assuming Figure 6 Given the identity account tree of the first user, if the account sequence number in the authentication request is 2, then the target AID account is AID2.

[0177] Step 1004: Generate the first zero-knowledge proof based on the target leaf node corresponding to the target AID account in the user account tree.

[0178] For example, Figure 6 The leaf node corresponding to the target AID account AID2 is N11, which is the target leaf node. Based on the target leaf node, a first zero-knowledge proof is generated. Specifically, based on the path from the target leaf node to the root node, the sibling nodes of each node included in this path are determined. Then, the plaintext or hash value of the target leaf node and the hash values ​​of each sibling node are used as the first zero-knowledge proof. For example, if the path from the target node N11 to the root node N1 includes nodes N11, N5, N2, and N1, where N11's sibling node is N10, N5's sibling node is N4, and N2's sibling node is N3, then the plaintext or hash value of N11, along with sibling nodes N10, N4, and N3, are used as the first zero-knowledge proof.

[0179] Step 1005: Based on the user identity attribute information required for issuing vLEI credentials carried in the authentication request, determine the target leaf node corresponding to the user identity attribute information in the user identity tree, and generate a second zero-knowledge proof based on the target leaf node.

[0180] Based on the user identity attribute information required for issuing a vLEI in the authentication request, the corresponding identity attribute information is extracted from the identity material information. Then, based on this identity attribute information in the leaf nodes of the user identity tree and the user identity tree itself, a second zero-knowledge proof is generated. For example, based on... Figure 4In the example shown, assuming the user identity attribute information required to issue a vLEI includes name and ID number, the target leaf nodes corresponding to the user identity attribute information in the user identity tree are determined. This means determining the target leaf nodes for the name and ID number in the user identity tree. For example, if the target leaf node for the name is N8 and the target leaf node for the ID number is N10, then the generated second zero-knowledge proof includes: the plaintext or hash value of the name recorded in target node N8, and the hash values ​​of multiple sibling nodes (N9, N5, N3) corresponding to multiple nodes included in the path from target node N8 to root node N1; the plaintext or hash value of the ID number recorded in target node N10, and the hash values ​​of multiple sibling nodes (N11, N4, N3) corresponding to multiple nodes included in the path from target node N10 to root node N1. The specific generation method for the second zero-knowledge proof is described in the above embodiment and will not be repeated here.

[0181] Step 1006: Return the real identity attribute information recorded in the target leaf node, the target AID account, the associated information corresponding to the target AID account (defined as target associated information), the first zero-knowledge proof, and the second zero-knowledge proof to the third QVI organization.

[0182] It should be noted that in step 1006, the first zero-knowledge proof includes the zero-knowledge proof corresponding to the target AID account and the zero-knowledge proof corresponding to the target associated information. For the specific content of the zero-knowledge proof, please refer to the explanation in step 515, which will not be repeated here.

[0183] After generating the second zero-knowledge proof, the identity attribute information recorded in the target leaf node (the leaf node corresponding to the user identity attribute information required to issue the vLEI credential) in the user identity tree, the target AID account in the user account tree, the associated information corresponding to the target AID account (defined as target associated information), and the first and second zero-knowledge proofs are returned to the third QVI institution to prove the authenticity and credibility of the user identity information and account information.

[0184] The third QVI institution can verify the user's identity and account information by comparing and executing the first and second zero-knowledge proofs, using the latest association records of the first user publicly available on the blockchain, combined with the alias information submitted by the user, the identity attribute information provided by the alias management platform, the AID account information, the association information corresponding to the AID account, and the corresponding first and second zero-knowledge proofs. If the verification is successful, the QVI institution accesses the OOBI address contained in the user account's association information, obtains the key event associated with that account, parses it, and then proceeds to issue vLEI credentials to that account.

[0185] In some application scenarios, users need to provide and display multiple vLEI credentials to the verification party simultaneously to meet business requirements. The method proposed in this application can also be used to verify identity information in vLEI credential display. Considering that a user may simultaneously hold multiple different AID accounts, and each account may be associated with multiple vLEI credentials issued by different QVIs, in this case, the user needs to prove to the verification party that the accounts to which these credentials belong all belong to their own name. The following details how users can quickly prove that credentials belong to accounts under their control using aliases, specifically, as follows... Figure 11 As shown, the vLEI credential ownership verification process may include the following steps: Step 1101: In response to receiving the identity query request for the first user sent by the second user; check whether the alias to be verified carried in the identity query request exists.

[0186] For example, the first user (vLEI credential holder) presents the required vLEI credential to the second user (verifier), along with its alias (alias to be verified).

[0187] The second user receives the vLEI credentials and alias (aliases to be verified) of the first user, and based on the AID account and alias contained in each vLEI credentials, constructs combined query conditions and initiates a structured query request (i.e. the identity query request in step 1101) to the alias management platform.

[0188] The identity query request is used to verify the authenticity of the vLEI credentials and aliases held by the first user.

[0189] The alias management platform searches the alias registration database based on the structured query request (identity query request) initiated by the second user. If no alias and / or AID account record that matches the structured query request is found, the alias management platform returns a "account does not exist" message to the second user.

[0190] Step 1102: If the alias to be verified exists, determine the target AID account corresponding to the alias to be verified.

[0191] If alias and / or AID account records that satisfy the structured query request are retrieved, the alias management platform selects all AID accounts that meet the combined query conditions as the target AID account. For example, suppose... Figure 4 The user account tree shown is the user account tree of the first user. The first user holds 4 AID accounts, and these 4 AID accounts are used as target AID accounts.

[0192] Step 1103: Generate a third zero-knowledge proof based on the target leaf node corresponding to the target AID account in the user account tree.

[0193] Based on the target leaf node of the target AID account in the user account tree and the user account tree, generate a third zero-knowledge proof. The third zero-knowledge proof includes the hash values ​​of multiple sibling nodes corresponding to the path from the target leaf node to the root node for each AID account, and the plaintext or hash value of the target leaf node.

[0194] Step 1104: Return the target AID account and the third zero-knowledge proof to the second user to trigger the second user to verify the authenticity of the vLEI certificate and alias held by the first user based on the third zero-knowledge proof and the associated records queried from the blockchain.

[0195] The target AID account information and the third zero-knowledge proof are returned to the second user to prove the authenticity and credibility of the first user's identity and account information.

[0196] The verifier (second user) obtains the query address of the latest association record corresponding to the first user on the blockchain. Based on the query address, it queries the latest publicly available association record corresponding to the first user on the blockchain. Combining the alias information submitted by the user, the target AID account information returned by the alias management platform, and the third zero-knowledge proof, it compares and verifies the user's identity information and account information and performs zero-knowledge proof verification. Finally, it confirms the authenticity of the user's identity and account ownership, thereby confirming that all vLEI credentials come from accounts controlled under that user name.

[0197] In summary, the distributed digital identity account processing method provided in this application relies on an authoritative alias management platform (CA institution) to complete identity authentication, assigning a globally unique and trustworthy alias to AID user entities, achieving accurate identification and management of AID user identities, and providing effective support for cross-QVI and cross-chain businesses. Furthermore, by constructing a user identity tree, a user account tree, and user identity credentials, the hash signature values ​​of the root nodes of the user identity tree and user account tree are combined with the hash value of the user identity credentials to generate associated records, which are stored in the alias registration database and proven in the blockchain. Zero-knowledge proofs are constructed based on the user identity tree and user account tree, enabling the verification party to prove the identity, account, and other related information associated with the user alias without disclosing additional sensitive user information.

[0198] The distributed digital identity account processing method provided in this application proposes a flexible method for updating and managing user aliases, user identities, and user accounts, and also proposes a faster and more secure AID account resolution process, as well as rapid identity verification in the vLEI issuance and display process.

[0199] The distributed digital identity account processing method provided in this application addresses the security issues faced by existing blockchain alias systems. In this scheme, the alias management platform (CA institution) is responsible for KYC authentication of AID users (including natural persons and legal entities). Only after successful authentication is the user assigned a globally unique and trustworthy alias, which is stored in a globally unique alias registry maintained by the alias management platform. This registration method effectively avoids malicious registration and tampering of aliases, ensuring the globally uniqueness and trustworthiness of user aliases. Furthermore, the user alias is included in the extended domain of the user identity credential and is further associated with and stored on the blockchain with the user's identity information and account information, forming an immutable "identity verification and storage chain." This allows the verifier to directly verify the user's identity information by comparing records on the chain, eliminating the need for the user to repeatedly submit materials. This approach leverages the transparency, traceability, and immutability of blockchain, along with the zero-knowledge proof capabilities of Merkle trees, to effectively ensure the security, trustworthiness, verifiability, and immutability of user aliases, user identity information, and user AID account information, without leaking any additional user privacy information. It achieves accurate identification, management, and efficient verification of user identities, providing users with a better user experience.

[0200] The distributed digital identity account processing method provided in this application addresses the limitations of existing alias systems in terms of scalability and interoperability. This solution leverages a user account tree, along with its association and storage with user credentials and the user identity tree, to achieve efficient management (including querying, adding, and deleting) of multiple AID account addresses under a single username. It also supports selective information disclosure (zero-knowledge proof) and protects user privacy, meeting various needs in cross-chain business scenarios.

[0201] The distributed digital identity account processing method provided in this application supports flexible changes to users' aliases, effectively solving the problem in existing alias systems where "once the binding is completed, it is difficult to adjust or dynamically update the alias." Furthermore, user identity information and user account information can also be dynamically updated according to user wishes, and the updated state (an associated record composed of the user credential hash, the hash signature value of the user identity tree root node, and the hash signature value of the user account tree root node) is stored on the blockchain. This method simplifies user operations and improves user experience. In addition, on-chain storage ensures the preservation of evidence related to user aliases, user identities, and on-chain accounts, providing authoritative support for judicial evidence collection and regulatory auditing.

[0202] The distributed digital identity account processing method provided in this application embodiment is based on an alias management platform, which enables users to verify and resolve AID accounts simply by sharing their aliases, avoiding cumbersome challenge / response processes, improving user experience, and ensuring the security and trustworthiness of the overall process based on blockchain and digital signature technology.

[0203] The distributed digital identity account processing method provided in this application effectively solves the problem of duplicate user identity verification by storing user identity and account information on the blockchain. Verifiers can more quickly verify user identities by comparing on-chain stored records. Simultaneously, the alias registration and resolution scheme based on an alias management platform effectively addresses challenges such as data silos and difficulties in cross-QVI and cross-chain communication.

[0204] The distributed digital identity account processing apparatus provided in the embodiments of this application is described below. The distributed digital identity account processing apparatus described below can be referred to in correspondence with the distributed digital identity account processing method described above.

[0205] This application provides a distributed digital identity account processing device. The corresponding product of this device can be an electronic device or a functional module of an electronic device used to implement the above functions.

[0206] Specifically, such as Figure 12 As shown in the embodiments of this application, a distributed digital identity account processing device may include: The receiving unit 1201 is used to receive an alias registration request for the first user sent by the first QVI organization.

[0207] Merkle tree creation unit 1202 is used to create a user account tree based on the first account association information corresponding to the first user carried in the alias registration request; the first account association information includes the first account registered by the first user in the first QVI institution; the user account tree is a Merkle tree including at least one pair of leaf nodes, and the first pair of leaf nodes in the at least one pair of leaf nodes is used to record the first account association information.

[0208] The generation unit 1203 is used to determine the first alias that is globally unique to the first user and generate the first identity credential; the extended field of the first identity credential includes the first alias.

[0209] The association unit 1204 is used to combine at least the first root hash signature value of the user account tree and the hash value of the first identity credential to generate a first association record, and to synchronously store the first association record on the blockchain.

[0210] Verification unit 1205 is used to respond to a query request submitted by the second user, determine the corresponding user account tree based on the alias to be verified carried in the verification request, generate a zero-knowledge proof based on the user account tree, and return the first account, the zero-knowledge proof and the first identity credential to the second user, so as to trigger the second user to verify the first account held by the first user based on the zero-knowledge proof and the first association record queried from the blockchain.

[0211] Figure 13 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 13 As shown, the electronic device may include: a processor 1310, a communication interface 1320, a memory 1330, and a communication bus 1340, wherein the processor 1310, the communication interface 1320, and the memory 1330 communicate with each other via the communication bus 1340. The processor 1310 can call a computer program stored in the memory 1330 to execute the steps of a distributed digital identity account processing method, such as including: The system receives an alias registration request for a first user from a first QVI institution; creates a user account tree based on the first account association information corresponding to the first user carried in the alias registration request; the first account association information includes the first account registered by the first user with the first QVI institution; the user account tree is a Merkle tree including at least one pair of leaf nodes, and the first pair of leaf nodes in the at least one pair of leaf nodes is used to record the first account association information; the first account is an AID account or a DID account; determines a globally unique first alias corresponding to the first user, binds the first alias to the user account tree, and generates a first identity credential; the extended field of the first identity credential includes the first alias; combines at least the first root hash signature value of the user account tree and the hash value of the first identity credential to generate a first association record, and synchronously stores the first association record on the blockchain; responds to a query request submitted by a second user, determines the corresponding user account tree according to the alias to be verified carried in the query request, generates a zero-knowledge proof based on the user account tree, and returns the first account, the zero-knowledge proof, and the first identity credential to the second user to trigger the second user to verify the first account held by the first user based on the zero-knowledge proof and the first association record queried from the blockchain.

[0212] Furthermore, the logical instructions in the aforementioned memory 1330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0213] On the other hand, embodiments of this application also provide a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the distributed digital identity account processing method provided in the above embodiments, such as including: The system receives an alias registration request for a first user from a first QVI institution; creates a user account tree based on the first account association information corresponding to the first user carried in the alias registration request; the first account association information includes the first account registered by the first user with the first QVI institution; the user account tree is a Merkle tree including at least one pair of leaf nodes, and the first pair of leaf nodes in the at least one pair of leaf nodes is used to record the first account association information; the first account is an AID account or a DID account; determines a globally unique first alias corresponding to the first user, binds the first alias to the user account tree, and generates a first identity credential; the extended field of the first identity credential includes the first alias; combines at least the first root hash signature value of the user account tree and the hash value of the first identity credential to generate a first association record, and synchronously stores the first association record on the blockchain; responds to a query request submitted by a second user, determines the corresponding user account tree according to the alias to be verified carried in the query request, generates a zero-knowledge proof based on the user account tree, and returns the first account, the zero-knowledge proof, and the first identity credential to the second user to trigger the second user to verify the first account held by the first user based on the zero-knowledge proof and the first association record queried from the blockchain.

[0214] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program for causing a processor to perform the steps of the methods provided in the above embodiments, such as including: The system receives an alias registration request for a first user from a first QVI institution; creates a user account tree based on the first account association information corresponding to the first user carried in the alias registration request; the first account association information includes the first account registered by the first user with the first QVI institution; the user account tree is a Merkle tree including at least one pair of leaf nodes, and the first pair of leaf nodes in the at least one pair of leaf nodes is used to record the first account association information; the first account is an AID account or a DID account; determines a globally unique first alias corresponding to the first user, binds the first alias to the user account tree, and generates a first identity credential; the extended field of the first identity credential includes the first alias; combines at least the first root hash signature value of the user account tree and the hash value of the first identity credential to generate a first association record, and synchronously stores the first association record on the blockchain; responds to a query request submitted by a second user, determines the corresponding user account tree according to the alias to be verified carried in the query request, generates a zero-knowledge proof based on the user account tree, and returns the first account, the zero-knowledge proof, and the first identity credential to the second user to trigger the second user to verify the first account held by the first user based on the zero-knowledge proof and the first association record queried from the blockchain.

[0215] Processor-readable storage media can be any available medium or data storage device that the processor can access, including but not limited to magnetic storage (such as floppy disks, hard disks, magnetic tapes, magneto-optical disks (MOs), etc.), optical storage (such as CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (such as ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)).

[0216] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0217] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0218] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A distributed digital identity account processing method, characterized in that, The method includes: Receive an alias registration request for the first user from the first QVI organization; Based on the first account association information corresponding to the first user carried in the alias registration request, a user account tree is created; the first account association information includes the first account registered by the first user in the first QVI institution; the user account tree is a Merkle tree including at least one pair of leaf nodes, and the first pair of leaf nodes in the at least one pair of leaf nodes is used to record the first account association information; the first account is an AID account or a DID account. A globally unique first alias corresponding to the first user is determined, the first alias is bound to the user account tree, and a first identity credential is generated; the extended domain of the first identity credential includes the first alias; The hash signature value of the first root of the user account tree and the hash value of the first identity credential are combined to generate a first association record, and the first association record is synchronously stored in the blockchain. In response to receiving a query request submitted by a second user, the system determines the corresponding user account tree based on the alias to be verified carried in the query request, generates a zero-knowledge proof based on the user account tree, and returns the first account, the zero-knowledge proof, and the first identity credential to the second user, so as to trigger the second user to verify the first account held by the first user based on the zero-knowledge proof and the first association record queried from the blockchain.

2. The method according to claim 1, characterized in that, Generating zero-knowledge proofs based on the user account tree includes: Identify the target account corresponding to the alias to be verified; A zero-knowledge proof is generated based on the target leaf node corresponding to the target account in the user account tree; the zero-knowledge proof includes the hash values ​​of each sibling node on the Merkel path from the target leaf node to the root node of the user account tree, and the hash value of the target leaf node.

3. The method according to claim 2, characterized in that, The target account is the default account; or, The query request also carries additional information; the target account is the account specified by the additional information.

4. The method according to claim 1, characterized in that, The alias registration request also carries first identity material information corresponding to the first user; the first identity material information includes at least one identity attribute information. The method further includes: Based on the identity material information, a user identity tree is created; the user identity tree is a Merkle tree including at least one leaf node, and the at least one leaf node corresponds one-to-one with the at least one identity attribute information; At least the hash signature value of the first root of the user account tree and the hash value of the first identity credential are combined to generate a first associated record, including: The root hash signature value of the user identity tree, the first root hash signature value of the user account tree, and the hash value of the first identity credential are combined to generate the first associated record.

5. The method according to claim 4, characterized in that, The method further includes: In response to receiving an alias registration request for the first user from the second QVI organization, and if it is determined from the first identity information that the first user has already registered a first alias, a second pair of leaf nodes is created in the user account tree corresponding to the first user; the second pair of leaf nodes is used to record the second account association information; the second account association information includes the second account registered by the first user with the second QVI organization; Bind the first account and the second account to the first alias; After creating the second pair of leaf nodes, the second root hash signature value of the user account tree is redefined; The root hash signature value of the user identity tree, the second root hash signature value of the user account tree, and the hash value of the first identity credential are combined to generate a second associated record; The second associated record is synchronously stored in the blockchain; Return the query address of the second associated record on the blockchain to the second QVI institution.

6. The method according to claim 5, characterized in that, The method further includes: In response to receiving an unbinding request for the first user from the second QVI organization, the binding between the second account and the first alias is released; the second pair of leaf nodes is deleted from the user account tree corresponding to the first user, and the third root hash signature value of the user account tree is re-determined; The root hash signature value of the user identity tree, the third root hash signature value of the user account tree, and the hash value of the first identity credential are combined to generate a third associated record; And the third associated record will be synchronously stored in the blockchain; Return the query address of the third associated record on the blockchain to the second QVI institution.

7. The method according to any one of claims 4-6, characterized in that, The method further includes: In response to receiving an identity information update request for a first user from a first QVI organization, the system verifies the updated second identity material information carried in the identity information update request and the authenticity of the first user. If the verification is successful, the system updates the identity attribute information recorded in the corresponding leaf node of the user identity tree. Determine the root hash signature value of the updated user identity tree; The updated root hash signature of the user identity tree, the root hash signature of the user account tree, and the hash value of the first identity credential are combined to generate a fourth association record; And the fourth associated record will be synchronously stored in the blockchain; Return the query address of the fourth associated record on the blockchain to the first QVI institution.

8. The method according to any one of claims 4-6, characterized in that, The method further includes: In response to receiving an alias update request for the first user sent by the first QVI organization, the system verifies the first identity material information carried in the alias update request and the authenticity of the first user. If the verification is successful, the system queries whether the second alias carried in the alias update request has been registered. If the second alias has already been registered, obtain the third alias corresponding to the first user; If the second alias has not been registered, a second identity credential is generated; the extended domain of the second identity credential includes the second alias. At least the root hash signature value of the user account tree and the hash value of the second identity credential are combined to generate a fifth association record, and the fifth association record is synchronously stored in the blockchain; Return the query address of the fifth associated record on the blockchain to the first QVI institution.

9. The method according to any one of claims 4-6, characterized in that, The method further includes: In response to receiving an authentication request for a first user sent by the first QVI authority; verifying the authenticity of the first user, and if the verification is successful, querying whether the alias to be verified carried in the authentication request exists; the authentication request is generated by the first QVI authority in response to the vLEI credential issuance request initiated by the first user; If the alias to be verified exists, determine the target account corresponding to the alias to be verified; Generate a first zero-knowledge proof based on the target leaf node corresponding to the target account in the user account tree; Based on the user identity attribute information required for issuing vLEI credentials carried in the authentication request, determine the target leaf node corresponding to the user identity attribute information in the user identity tree, and generate a second zero-knowledge proof based on the target leaf node. The true identity attribute information recorded in the target leaf node, the target account, the target association information corresponding to the target account, the first zero-knowledge proof, and the second zero-knowledge proof are returned to the first QVI organization.

10. The method according to any one of claims 2-6, characterized in that, The method further includes: In response to receiving an identity query request for the first user sent by the second user; querying whether the alias to be verified carried in the identity query request exists; the identity query request is used to verify the authenticity of the vLEI credential held by the first user and the alias; If the alias to be verified exists, determine the target account corresponding to the alias to be verified; A third zero-knowledge proof is generated based on the target leaf node corresponding to the target account in the user account tree. The target account and the third zero-knowledge proof are returned to the second user to trigger the second user to verify the authenticity of the vLEI certificate and alias held by the first user based on the third zero-knowledge proof and the first association record queried from the blockchain.

11. A distributed digital identity account processing device, characterized in that, The device includes: The receiving unit is used to receive an alias registration request for the first user sent by the first QVI organization; The Merkle tree creation unit is used to create a user account tree based on the first account association information corresponding to the first user carried in the alias registration request; the first account association information includes the first account registered by the first user in the first QVI institution; the user account tree is a Merkle tree including at least one pair of leaf nodes, and the first pair of leaf nodes in the at least one pair of leaf nodes is used to record the first account association information. The generation unit is configured to determine a globally unique first alias corresponding to the first user and generate a first identity credential; the extended domain of the first identity credential includes the first alias; The association unit is used to combine at least the first root hash signature value of the user account tree and the hash value of the first identity credential to generate a first association record, and to synchronously store the first association record on the blockchain; The verification unit is configured to respond to a query request submitted by a second user, determine the corresponding user account tree based on the alias to be verified carried in the query request, generate a zero-knowledge proof based on the user account tree, and return the first account, the zero-knowledge proof, and the first identity credential to the second user, so as to trigger the second user to verify the first account held by the first user based on the zero-knowledge proof and the first association record queried from the blockchain.

12. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the distributed digital identity account processing method according to any one of claims 1 to 10.

Images