Distributed digital identity implementation method and system with custom attributes for real-name authentication and storage medium

Abstract

The present application discloses a distributed digital identity implementation method and system and storage medium with custom attributes of real-name authentication. In the embodiment of the present application, the verification node verifies the identity of the user by real name according to the identity information of the user encrypted by the public key of the verification node sent by the access node; when the real-name verification result is passed, the verification node generates a real-name DID identifier for the user, and generates the real-name DID document of the user according to the real-name DID identifier and the public key of the user, and the real-name DID document is signed by the verification node using its own private key to generate the real-name DID document; the verification node uploads the real-name DID document to the blockchain. Therefore, the present application not only eliminates the risk of forwarding the user's privacy data to the outside of the chain in the prior art, but also includes the signature of the authority for the verification result in the user's real-name DID identity, instead of the signature only performed by the operator of the DID platform in the prior art, so that the real-name DID identity based on real-name authentication can be realized on the blockchain, which greatly improves the versatility of the real-name DID identity.

Description

Technical Field

[0001] The present application relates to the field of network technology, and in particular to a distributed digital identity implementation method and system and a storage medium with custom attributes for real-name authentication. Background Art

[0002] With the continuous advancement of trusted technologies, especially blockchain technology, distributed digital identity (DID) application solutions have emerged, which has brought revolutionary changes to more and more traditional IT systems. These systems can now use distributed digital identities to enable users to independently control their personal data and assets, and realize decentralized data sharing across departments, industries, and regions. In addition, as the most authoritative and influential standardization organization in the field of Web technology, the World Wide Web Consortium (W3C) launched the first DID standard specification in 2019, which marks an important step forward in the normalization and standardization of DID technology.

[0003] With the widespread application of DID identities, the use of DID identities needs to be further standardized and supervised. At present, DID identities are mostly authenticated and issued by the business party themselves, and this process faces technical and management challenges in implementing real-name authentication. Since the operators behind the platforms that generate DID identities manage their own backend systems, when user identity information needs to be verified, the user's sensitive information usually needs to be submitted to an authority for additional verification. These authorities are responsible for real-name verification of the information submitted by the business server and feedback the results to the business server that issued the DID identity. In this process, the user's private information needs to be sent outside the chain, which poses potential risks to privacy protection and identity authentication processes in the current system. To this end, a technical solution is needed that can ensure the security of user privacy information during real-name authentication and realize the interoperability and sharing of DIDs between different application platforms. Summary of the invention

[0004] The embodiments of the present application provide a distributed digital identity implementation method and system and a storage medium with custom attributes for real-name authentication, so as to solve the defects in the prior art in that privacy data is insecure when implementing real-name DID identity for users and DIDs between different platforms cannot communicate with each other.

[0005] To achieve the above-mentioned purpose, the embodiment of the present application provides a distributed digital identity implementation method with custom attributes of real-name authentication, which is applied to a blockchain, wherein the blockchain includes an access node and a verification node, and the method includes:

[0006] The access node receives a real-name DID generation request initiated by a user, wherein the real-name DID generation request at least includes identity information of the user;

[0007] The verification node performs real-name verification on the user's identity according to the user's identity information sent by the access node;

[0008] When the real-name verification result is passed, the verification node generates a real-name DID identifier for the user, and generates a real-name DID document of the user according to the real-name DID identifier and the user's public key, wherein the real-name DID document is signed by the verification node using its own private key;

[0009] The verification node uploads the real-name DID document to the blockchain.

[0010] The embodiment of the present application also provides a distributed digital identity implementation system with custom attributes of real-name authentication, including: a service node, an access node and a verification node, wherein the access node and the verification node are deployed on a blockchain, and

[0011] The service node is used to: send a real-name DID generation request initiated by a user to the access node, wherein the real-name DID generation request at least includes the identity information of the user;

[0012] The access node is used to: receive the real-name DID generation request sent by the service node, and send the user identity information contained in the real-name DID generation request to the verification node;

[0013] The verification node is used to: perform real-name verification on the identity of the user according to the identity information of the user sent by the access node; when the real-name verification result is passed, generate a real-name DID identifier for the user, and generate a real-name DID document for the user according to the real-name DID identifier and the user's public key, wherein the real-name DID document is signed by the verification node using its own private key, and the real-name DID document is uploaded to the blockchain.

[0014] The present application also provides an electronic device, including:

[0015] Memory, used to store programs;

[0016] A processor is used to run the program stored in the memory, and when the program is run, the distributed digital identity implementation method with custom attributes of real-name authentication provided in an embodiment of the present application is executed.

[0017] An embodiment of the present application also provides a computer-readable storage medium on which a computer program executable by a processor is stored, wherein when the program is executed by the processor, the method for implementing a distributed digital identity with custom attributes for real-name authentication as provided in an embodiment of the present application is implemented.

[0018] The distributed digital identity implementation method and system and storage medium with custom attributes of real-name authentication provided by the embodiment of the present application perform real-name authentication on the identity of the user by the verification node according to the identity information of the user sent by the access node; when the real-name verification result is passed, the verification node generates a real-name DID identifier for the user, and generates a real-name DID document of the user according to the real-name DID identifier and the user's public key, and the real-name DID document is signed by the verification node using its own private key to generate the real-name DID document; the verification node uploads the real-name DID document to the blockchain. Therefore, the present application not only eliminates the risk of forwarding the user's privacy data to the outside of the chain in the prior art, but also includes the signature of the authority for the verification result in the user's real-name DID identity, instead of the signature only performed by the operator of the DID platform in the prior art, so that the real-name DID identity based on real-name authentication can be realized on the blockchain, which greatly improves the versatility of the real-name DID identity.

[0019] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present application. Also, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0021] Figure 1 It is a schematic diagram showing an application scenario of a distributed digital identity implementation solution with custom attributes for real-name authentication according to an embodiment of the present application;

[0022] Figure 2 A flowchart of an embodiment of a method for implementing a distributed digital identity with custom attributes for real-name authentication provided by the present application;

[0023] Figure 3 A schematic diagram of the structure of a distributed digital identity implementation system with custom attributes for real-name authentication provided for this application;

[0024] Figure 4A schematic diagram of the structure of an electronic device embodiment provided in this application. DETAILED DESCRIPTION

[0025] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0026] Embodiment 1

[0027] The solution provided in the embodiments of the present application can be applied to any data system or server with encryption and decryption functions.

[0028] With the development of Internet technology, people can live and work more and more through the Internet, and therefore, various websites built on the Internet have emerged to provide users with various services. Due to the identity anonymity of the Internet, websites often cannot know the real identity of users who visit or log in to their websites, and therefore cannot regulate and manage the use of services by users accordingly. For this reason, it has been proposed in the prior art that users need to pre-register their identity information in the websites they visit or log in to, so that the websites can provide services to users based on the identity information submitted by users when users request to use the services of the websites. In this process, users need to provide the original data of their identity information to the website and then save it in the server of the website, but such identity information is usually the user's private data. Therefore, when users use the services provided by different websites, they also have to store their private data on various websites, which greatly increases the risk of user privacy exposure.

[0029] In this regard, the DID (decentralized identity) system has been proposed in the prior art. This system is mainly proposed for the above-mentioned existing centralized identity system in which each website manages the identity information of users. Since the identity registration modules of most different websites or platforms are not interoperable, most websites or platforms of different operators currently do not have the authority to access or even manage the identity data of each other's websites, and cannot verify the identity of users who use the identity identifiers issued by each other's websites.

[0030] In the DID system, users can request identity authentication from the operator of the DID platform, and the operator can generate a request based on the user's DID identity to verify the identity information requested by the user and issue a DID identity to the user after the verification is passed. Figure 1Schematic diagram showing an application scenario of a DID implementation solution according to an embodiment of the present application. Figure 1 In the scenario shown in , the user can log in to the business system he wants to use, for example, by logging in to the business node of the business system to use the business in the system. When the system supports or requires users to use real-name DID identities, users can initiate real-name DID generation requests in the system. For example, if a user wants to use a payment service, he can log in to the business node of the business platform that provides the payment service to submit a payment request. As mentioned above, such a business platform can require users to use real-name DID identities to perform various payment services to improve the security of user payment services.

[0031] However, in general, the business platform itself does not have the ability to generate real-name DID identities. In other words, the business platform itself usually does not have the ability to verify the user's identity. Figure 1 As shown in , when a user initiates a real-name DID identity generation request on a business platform according to the requirements of the business platform, the business platform can forward the user's real-name DID generation request to the DID operation platform that provides the DID generation service. Figure 1As shown in , the business platform can forward the user's request to the access node of the DID operation platform, so that the access node can request the background node of the DID operation platform to perform identity authentication and generation processing according to the identity information contained in the request. In the prior art, although the DID operation platform can store some information of the user, it is not an authoritative identity authentication agency. To this end, in the prior art, the DID operation platform usually needs to send the identity information contained in the real-name DID generation request of the user, especially the privacy information that identifies its identity, such as the ID card number or the face image, to the authority outside the chain. In the embodiment of the present application, these authoritative agencies can be agencies with identity authentication qualifications, such as government departments, banks or other identity management agencies established in accordance with legal provisions. Therefore, these authoritative identity authentication agencies can verify the privacy information of the user forwarded by the DID operation platform according to the identity information of the user stored therein. For example, the corresponding verification information, such as the face image, can be searched in the database according to the identity identifier such as the user's name or ID card number, and then the found face image is compared with the face image sent by the operation platform, and if the similarity is greater than the predetermined threshold, the authority can generate a verification result that has been verified and send it to the background node of the operation platform. The backend node of the operation platform can create a DID document based on the verification results fed back by the authority. The document may contain information such as the user's DID identifier, the public key of the operation platform, and the verification method on the operation platform. Finally, the operation platform can upload the DID document to the blockchain, thereby generating a real-name DID identity for the user that can be used on the operation platform and in the business systems connected to the operation platform.

[0032] In the process of the prior art, since the DID operating platform itself does not have the ability to verify the user's identity information by real name, the operating platform needs to send the privacy data in the DID identity request sent by the user to the corresponding authority outside the chain for authentication, and the authority only verifies the privacy data sent by the background node and sends the verification result back to the background node. The background node will generate a real-name DID document for the user when the verification result is true to generate a real-name DID identity used by the user. Therefore, the DID solution of the prior art has the risk of leakage caused by the forwarding of user privacy data, which greatly deteriorates the user's experience of using the DID identity, and since the real-name DID identity obtained by the user is generated by the operating platform of the DID identity, therefore, in the case of multiple DID identity operating platforms, the DID identities generated by different operating platforms cannot be universal, but can only be used in the business system connected to the operating platform, therefore, the scope of use of the user's real-name DID identity is greatly limited, and it also brings inconvenience to the user to use the real-name DID identity on different business platforms.

[0033] To this end, according to an embodiment of the present application, a distributed digital identity implementation scheme with custom attributes of real-name authentication is provided, which can directly perform real-name verification on the user's identity through a verification node set up by an authoritative organization on the blockchain, and the verification node directly generates a real-name DID document and uploads it to the blockchain, thereby eliminating the security risk of the prior art that requires the user's privacy data to be forwarded to an authority outside the chain for authentication, and also ensures that the real-name DID identity obtained by the user is issued by the same authority, thereby achieving universality across different platforms.

[0034] For example, Figure 1 As shown in, in the distributed digital identity implementation scheme with custom attributes of real-name authentication provided in the embodiment of the present application, the user can initiate a real-name DID generation request on the business node after logging in to the business node, or the user can also use the client to directly initiate a real-name DID generation request to the access node on the blockchain. In the embodiment of the present application, the blockchain where the access node is located can be a blockchain that provides real-name DID services for special users, and one or more access nodes can be set on the blockchain to receive real-name DID requests sent by various business systems or business nodes, and one or more authoritative agencies, such as government departments, banks or other identity management agencies with identity authentication qualifications established in accordance with legal provisions, can also be set on the blockchain. The real-name DID generation request initiated by the user may at least contain the user's identity information, such as the user's name, ID number, address, face image and other information related to the user's identity. In the embodiment of the present application, the business node can be one of the multiple nodes of the business system that provides various services for users, that is, the user can log in to a certain business node by logging in to the business system, and can initiate a business request on the business node.

[0035] After receiving a DID generation request sent by a user directly or through a service node, the access node can forward it to the verification node, or it can also forward only the user's identity information contained therein to the verification node. For example, when a user or service node sends a real-name DID generation request to an access node, it can package identity information, such as identity document information and biometric information, according to the format requirements of the access node to generate a DID request, and encrypt it using the public key of the verification node, and then send the encrypted request to the access node. Therefore, after receiving the DID generation request, the access node can directly forward it to the verification node.

[0036] After receiving the identity information sent by the access node, the verification node can perform real-name verification on the identity of the user. The verification node can use its private key to decrypt the encrypted identity information sent by the access node to obtain the identity information to be verified. Then, the verification node can use its own stored identity data to perform real-name verification on the identity information to be verified based on the user's identity identifier contained in the identity information or the identity identifier sent along with the identity information to generate a real-name verification result. In an embodiment of the present application, the real-name verification result can indicate that the user's identity identifier and identity information contained in the identity information to be verified sent by the access node are consistent with the identity data stored in the verification node. For example, the verification node can search for the corresponding identity information in its stored identity data based on the user identifier contained in the decrypted identity information, such as the user's name or ID card information, to obtain the corresponding identity information, such as the biometric information corresponding to the user's name or ID card information, and compare the biometric information found with the biometric information contained in the identity information sent by the access node. When the similarity is greater than a predetermined threshold, it can be determined that the user's identity authentication is passed, that is, the real-name verification result for the user is passed. Then, the verification node can generate a real-name DID identifier for the user, and generate a real-name DID document for the user based on the real-name DID identifier and the user's public key. In an embodiment of the present application, after generating the real-name DID document, the verification node can use its own private key to sign the generated real-name DID document, and then upload the real-name DID document to the blockchain. For example, the verification node can upload the real-name DID document to the blockchain through the real-name DID contract deployed on the blockchain. The access node can obtain the real-name DID document through the real-name DID contract and send it to the business node for the user to use in the business system.

[0037] In addition, as mentioned above, there are currently various DID operating platforms that provide DID identities. When using the services of the business systems connected to these DID operating platforms, users have applied for DID identities from the corresponding DID operating platforms, but these DID identities have not been authenticated by the authoritative agency. In this case, the user does not want to use the existing technology to have these operating platforms send their privacy information to the authoritative agency to achieve real-name authentication, but they need to use the real-name authenticated DID identity on these business platforms. To this end, in an embodiment of the present application, the user can initiate a custom real-name DID generation request to the access node directly or through a business node when the authoritative agency has generated a real-name DID identifier for it through the real-name DID generation scheme as described above. The custom DID generation request may include a non-real-name DID identifier and the user's identity identifier.

[0038] The access node can search for the user's real-name DID identifier through the verification node based on the user's encrypted identity identifier encrypted using the verification node's public key. If the corresponding real-name DID identifier does not exist, it can feedback to the user or service node that the real-name DID identifier does not exist, and require or prompt the user to initiate a real-name DID generation request, or it can request the user's identity information from the corresponding operation platform based on the non-real-name DID identifier, and then generate a real-name DID for the user through the solution described above.

[0039] In the case of determining that there is a corresponding real-name DID identifier, the access node can query the DID document corresponding to the real-name DID identifier contained in this request on the blockchain, and verify whether its signature is made by the verification node set by the authority on the same blockchain based on the real-name DID document. If there is a real-name DID document signed by an authority, that is, the corresponding verification node, the access agency can further verify whether the non-real-name DID identifier has been associated with the real-name DID identifier, for example, it can verify whether the non-real-name DID identifier is signed by the access node. If not, the access node can generate a custom DID identifier based on the non-real-name DID identifier and the found real-name DID identifier, for example, the custom DID identifier can be generated by splicing the non-real-name DID identifier and the real-name DID identifier together. The access node can then sign the custom DID identifier using its private key and return the signature value to the service node. Then, the service node can write the signature value, non-real-name DID identifier, and real-name DID identifier generated by the access node into the custom DID document to generate a custom DID document. Therefore, according to an embodiment of the present application, when a user already has a non-real-name DID used in a business system, information indicating that the user has obtained real-name authentication from an authoritative organization can be added to the DID document in the above manner, thereby enabling the user's original non-real-name DID identity in the business system to have the attribute of real-name authentication.

[0040] The above embodiments are illustrations of the technical principles and exemplary application frameworks of the embodiments of the present application. The specific technical solutions of the embodiments of the present application are further described in detail below through multiple embodiments.

[0041] Embodiment 2

[0042] Figure 2The flowchart of the embodiment of the method for implementing a distributed digital identity with custom attributes of real-name authentication provided by the present application, the execution subject of the method can be various terminals or server devices with data encryption and decryption capabilities deployed on the blockchain, or it can be a device or chip integrated on these devices. In particular, in the embodiment of the present application, at least one access node and at least one verification node can be deployed on the blockchain, and the verification node can be set by an authority. Figure 2 As shown, the distributed digital identity implementation method with custom attributes of real-name authentication includes the following steps:

[0043] S201, an access node receives a real-name DID generation request initiated by a user.

[0044] In step S201, the access node deployed on the blockchain may receive a real-name DID generation request directly initiated by the user or initiated on the business node of the business system to which the user logs in. In an embodiment of the present application, the user may initiate a real-name DID generation request on the business node after logging in to the business node, or the user may also use the client to directly initiate a real-name DID generation request to the access node on the blockchain, so that the access node may receive the real-name DID generation request initiated by the user in step S201. The real-name DID generation request initiated by the user may at least include the user's identity information, such as the user's name, ID number, address, facial image, and other information related to the user's identity.

[0045] In an embodiment of the present application, the blockchain where the access node is located may be a blockchain that provides real-name DID services to special users. One or more access nodes may be set on the blockchain to receive real-name DID requests sent by various business systems or business nodes. In addition, verification nodes directly set up by one or more authoritative agencies may also be set on the blockchain, such as verification nodes set up by government departments, banks or other identity management agencies established in accordance with legal provisions and with identity authentication qualifications.

[0046] After receiving the DID generation request sent by the user directly or through the service node in step S201, the access node may further forward it to the verification node, or may only forward the user's identity information encrypted using the public key of the verification node to the verification node. For example, when the user or service node sends the real-name DID generation request to the access node, the identity information, such as identity document information and biometric information, may be packaged according to the format requirements of the access node or the verification node to generate a DID request, and encrypted using the public key of the verification node, and then the encrypted request is sent to the access node. Therefore, after receiving the DID generation request in step S201, the access node may directly forward it to the verification node. Then, the access node may perform source verification on the real-name DID generation request to determine whether it meets the source requirements. When the result of the verification indicates that the real-name DID generation request received by the access node in step S201 meets the requirements, the access node may send it to the verification node for verification.

[0047] S202: The verification node performs real-name verification on the user's identity based on the user's identity information sent by the access node.

[0048] In step S202, the verification node may perform real-name verification on the user's identity according to the user's identity information sent by the access node. In step S202, the verification node may first use its private key to decrypt the encrypted identity information sent by the access node to obtain the identity information to be verified.

[0049] In step S202, the verification node can perform real-name verification on the identity information to be verified based on the identity identifier of the user contained in the identity information sent by the access node or the identity identifier sent along with the identity information using the identity data stored by itself to generate a real-name verification result. In an embodiment of the present application, the real-name verification result can indicate that the identity identifier and identity information of the user contained in the identity information to be verified sent by the access node are consistent with the identity data stored in the verification node. For example, the verification node can search in the identity data stored in it based on the user identifier contained in the decrypted identity information, such as the user's name or ID card information, to obtain the corresponding identity information, such as the biometric information corresponding to the user's name or ID card information, and compare the biometric information found with the biometric information contained in the identity information sent by the access node. When the similarity is greater than a predetermined threshold, it can be determined that the identity authentication of the user is passed, that is, the real-name verification result for the user is passed. When the similarity is lower than the predetermined threshold, the verification node can determine that the identity authentication of the user is not passed, and can send the verification result indicating failure to the access node.

[0050] S203, when the real-name verification result is passed, the verification node generates a real-name DID identifier for the user, and generates a real-name DID document for the user based on the real-name DID identifier and the user's public key.

[0051] S204, the verification node uploads the real-name DID document to the blockchain.

[0052] In step S203, the verification node can generate a real-name DID identifier for the user when the result of the real-name verification performed in step S202 is verified to be passed, that is, when the identity data corresponding to the user's identity identifier is consistent with the identity data of the authority stored in the verification node, and generate the user's real-name DID document based on the real-name DID identifier and the user's public key. In step S203, after generating the real-name DID document, the verification node can use its own private key to sign the generated real-name DID document, and then upload the real-name DID document to the blockchain in step S204. For example, the verification node can upload the real-name DID document to the blockchain through the real-name DID contract deployed on the blockchain in step S204. The access node can obtain the real-name DID document through the real-name DID contract and send it to the business node for the user to use in the business system.

[0053] In addition, according to an embodiment of the present application, after step S204, the user also initiates a custom real-name DID generation request to the access node directly or through a service node. The custom DID generation request may include a non-real-name DID identifier and a user's identity identifier. The non-real-name DID identifier may be generated by, for example, various DID operation platforms that provide DID services in the prior art, and can be used by users in the corresponding service platform, but such a non-real-name DID identity does not have a real-name attribute, so when the service platform requires the use of a real-name DID identity for regulatory or security reasons, it will cause the user to be unable to perform business processing. To this end, in an embodiment of the present application, when a real-name DID identifier is generated for the user in step S203, the access node can search for the user's real-name DID identifier based on the user's identity identifier in the custom real-name DID generation request sent by the user. For example, the access node can call the real-name DID contract according to the user's identity to query the real-name DID identifier and the real-name DID document corresponding to the identity identifier. If the real-name DID document is queried, the access node can use the public key of the verification node to perform signature verification on the real-name DID document to determine that the real-name DID document is generated by the verification node. When the signature verification result indicates that the real-name DID document is generated by the verification node, the access node can further determine whether there is a custom real-name DID signature value corresponding to the non-real-name DID identifier, that is, determine whether there is a custom DID identity generated for the non-real-name DID identifier of the user. When the access node confirms that there is no custom real-name DID signature value corresponding to the non-real-name DID identifier, the access node can generate a custom real-name DID identifier based on the acquired real-name DID identifier and the non-real-name DID identifier. The service node can also include the real-name DID identifier that the access node has generated for the user in the custom real-name DID generation request and send it to the access node.

[0054] In addition, if the corresponding real-name DID identifier does not exist, the user or business node can be fed back that the real-name DID identifier does not exist, and the user can be required or prompted to initiate a real-name DID generation request, so that the user can generate a real-name DID identity for the user through the above steps S201-S204, or the user's identity information can be requested from the corresponding operating platform based on the non-use DID identifier, and then a real-name DID identity can be generated for the user through the above steps S201-S204.

[0055] When the user's real-name DID is obtained, the access node can generate a custom real-name DID based on the obtained real-name DID and the non-real-name DID. For example, the custom DID can be generated by concatenating the non-real-name DID and the real-name DID.

[0056] Then, the access node can sign the custom real-name DID identifier with its private key to generate a custom real-name DID signature value, and send the custom real-name DID signature value to the service node. Then, the service node can write the custom real-name DID signature value, the non-real-name DID identifier, and the real-name DID identifier into the non-real-name DID document corresponding to the non-real-name DID identifier to generate a custom real-name DID document, so that the user's custom real-name DID document has a real-name DID generated by the verification node of the authority, so that the DID identity has real-name attributes and can meet increasingly stringent regulatory requirements.

[0057] The distributed digital identity implementation method with custom attributes of real-name authentication provided by the embodiment of the present application is that the verification node verifies the user's identity by real name according to the user's identity information sent by the access node; when the real-name verification result is passed, the verification node generates a real-name DID identifier for the user, and generates the user's real-name DID document based on the real-name DID identifier and the user's public key, and the real-name DID document is signed by the verification node using its own private key to generate the real-name DID document; the verification node uploads the real-name DID document to the blockchain. Therefore, the present application not only eliminates the risk of forwarding the user's privacy data to the outside of the chain in the prior art, but also includes the signature of the authority for the verification result in the user's real-name DID identity, instead of the signature only performed by the operator of the DID platform in the prior art, and can realize the real-name DID identity based on real-name authentication on the blockchain, greatly improving the versatility of the real-name DID identity.

[0058] Embodiment 3

[0059] Figure 3 This is a schematic diagram of the structure of a distributed digital identity implementation system with custom attributes for real-name authentication provided by the present application. The distributed digital identity implementation system with custom attributes for real-name authentication can be used to implement, for example, Figure 2 The distributed digital identity implementation method with custom attributes of real-name authentication provided by the described embodiment of the present application. The distributed digital identity implementation system with custom attributes of real-name authentication may include: a business node 31 and a blockchain 34, on which an access node 32 and a verification node 33 may be deployed. In the embodiment of the present application, the access node 32 may be one or more, and the verification node 33 may be a node set by an authoritative organization, such as a verification node set by a government department, a bank or other identity management organization with identity authentication qualifications established in accordance with legal provisions, and may also be one or more.

[0060] The service node 31 may be used to send a real-name DID generation request initiated by the user to the access node 32. In the embodiment of the present application, the user may initiate the real-name DID generation request by logging into the service node 31 of the service system used by the user, or may directly initiate the real-name DID generation request to the access node 32. In the embodiment of the present application, the real-name DID generation request initiated by the user may at least include the user's identity information, for example, the user's name, ID number, address, face image, and other information related to the user's identity.

[0061] In addition, when the business node 31 sends a real-name DID generation request to the access node 32, it can package identity information, such as identity document information and biometric information, into a DID request according to the format requirements of the access node 32 or the verification node 33, and encrypt it using the public key of the verification node 32, and then send the encrypted request to the access node 32.

[0062] The access node 32 may be used to receive a real-name DID generation request sent by the service node 31 , and to send the user's identity information encrypted using the public key of the verification node 33 to the verification node 33 .

[0063] The access node 32 may perform source verification on the real-name DID generation request to determine whether the real-name DID generation request meets the source requirements. When the verification result indicates that the real-name DID generation request meets the source requirements, the access node 32 may send it to the verification node 33 for real-name verification.

[0064] The verification node 33 can be used to perform real-name verification on the user's identity based on the user's identity information sent by the access node 32; when the real-name verification result is passed, a real-name DID identifier is generated for the user, and a real-name DID document of the user is generated based on the real-name DID identifier and the user's public key, and the real-name DID document is uploaded to the blockchain 34.

[0065] For example, the verification node 33 may perform real-name verification on the user's identity based on the user's identity information sent by the access node 32. When the service node 31 encrypts the identity information using the public key of the verification node 33 and then sends it, the verification node 33 may first use its private key to decrypt the encrypted identity information sent by the access node 32 to obtain the identity information to be verified.

[0066] The verification node 33 can perform real-name verification on the identity information to be verified based on the user's identity identifier contained in the identity information sent by the access node 32 or the identity identifier sent along with the identity information using its own stored identity data to generate a real-name verification result. In an embodiment of the present application, the real-name verification result can indicate that the user's identity identifier and identity information contained in the identity information to be verified sent by the access node 32 are consistent with the identity data stored in the verification node 33. For example, the verification node 33 can search for the corresponding identity information, such as the user's name or ID card information, in the identity data stored in it based on the user identifier contained in the decrypted identity information, such as the user's name or ID card information, and compare the biometric information found with the biometric information contained in the identity information sent by the access node 32. When the similarity is greater than a predetermined threshold, it can be determined that the identity authentication of the user is passed, that is, the real-name verification result for the user is passed. When the similarity is lower than the predetermined threshold, the verification node 33 can determine that the identity authentication of the user is not passed, and can send the verification result indicating failure to the access node.

[0067] When the result of the real-name verification is verified, that is, the identity data corresponding to the user's identity identifier is consistent with the identity data of the authority stored in the verification node 33, the verification node 33 can generate a real-name DID identifier for the user, and generate a real-name DID document for the user based on the real-name DID identifier and the user's public key. For example, after generating the real-name DID document, the verification node 33 can use its own private key to sign the generated real-name DID document, and then upload the real-name DID document to the blockchain 34. For example, the verification node 33 can upload the real-name DID document to the blockchain 34 through the real-name DID contract deployed on the blockchain 34. The access node 32 can obtain the real-name DID document through the real-name DID contract and send it to the business node 31 for the user to use in the business system.

[0068] In addition, according to an embodiment of the present application, the user also initiates a custom real-name DID generation request to the access node 32 directly or through the business node 31. The custom DID generation request may include a non-real-name DID identifier and the user's identity identifier. The non-real-name DID identifier may be generated by, for example, various DID operation platforms that provide DID services in the prior art, and can be used by users in the corresponding business platform, but such a non-real-name DID identity does not have a real-name attribute, so when the business platform requires the use of a real-name DID identity for regulatory or security reasons, it will cause the user to be unable to perform business processing. To this end, in an embodiment of the present application, when the verification node 33 generates a real-name DID identifier for the user, the access node 32 can search for the user's real-name DID identifier based on the user's identity identifier in the custom real-name DID generation request sent by the business node 31. For example, the access node 32 may call the real-name DID contract according to the user's identity to query the real-name DID identifier and the real-name DID document corresponding to the identity identifier. If the real-name DID document is queried, the access node 32 may use the public key of the verification node 33 to perform signature verification on the real-name DID document to determine that the real-name DID document is generated by the verification node 33. When the signature verification result indicates that the real-name DID document is generated by the verification node 33, the access node 32 may further determine whether there is a custom real-name DID signature value corresponding to the non-real-name DID identifier on the blockchain 34, that is, determine whether a custom DID identity generated for the non-real-name DID identifier of the user already exists on the blockchain 34. When the access node 32 confirms that there is no custom real-name DID signature value corresponding to the non-real-name DID identifier on the blockchain 34, the access node 32 may generate a custom real-name DID identifier based on the acquired real-name DID identifier and the non-real-name DID identifier.

[0069] In addition, if there is no corresponding real-name DID identifier, the user or business node 31 can be fed back that the real-name DID identifier does not exist, and the user can be required or prompted to initiate a real-name DID generation request to generate a real-name DID identity for the user, or the user's identity information can be requested from the corresponding operating platform based on the non-use DID identifier, and then sent to the verification node 33 to generate a real-name DID identity for the user.

[0070] When the real-name DID of the user is obtained, the access node 32 can generate a custom real-name DID according to the obtained real-name DID and the non-real-name DID. For example, the custom DID can be generated by concatenating the non-real-name DID and the real-name DID.

[0071] Then, the access node 32 can sign the custom real-name DID identifier using its private key to generate a custom real-name DID signature value, and send the custom real-name DID signature value to the service node 31. Then, the service node 31 can write the custom real-name DID signature value, the non-real-name DID identifier, and the real-name DID identifier into the non-real-name DID document corresponding to the non-real-name DID identifier to generate a custom real-name DID document, so that the user's custom real-name DID document has a real-name DID generated by the verification node 33 of the authority, so that the DID identity has real-name attributes and can meet increasingly stringent regulatory requirements.

[0072] The distributed digital identity implementation system with custom attributes of real-name authentication provided by the embodiment of the present application performs real-name authentication on the identity of the user by the verification node according to the identity information of the user sent by the access node; when the real-name verification result is passed, the verification node generates a real-name DID identifier for the user, and generates a real-name DID document for the user according to the real-name DID identifier and the user's public key, and the real-name DID document is signed by the verification node using its own private key to generate the real-name DID document; the verification node uploads the real-name DID document to the blockchain. Therefore, the present application not only eliminates the risk of the prior art forwarding the user's private data to the outside of the chain, but also includes the signature of the authority for the verification result in the user's real-name DID identity, instead of the signature only performed by the operator of the DID platform in the prior art, and can realize the real-name DID identity based on real-name authentication on the blockchain, greatly improving the versatility of the real-name DID identity.

[0073] Embodiment 4

[0074] The above describes the internal functions and structure of a distributed digital identity implementation system with custom attributes for real-name authentication, which can be implemented as an electronic device. Figure 4 This is a schematic diagram of the structure of an electronic device embodiment provided by this application. Figure 4 As shown, the electronic device includes a memory 41 and a processor 42 .

[0075] The memory 41 is used to store programs. In addition to the above programs, the memory 41 can also be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device, contact data, phone book data, messages, pictures, videos, etc.

[0076] The memory 41 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0077] The processor 42 is not limited to a processor (CPU), but may also be a processing chip such as a graphics processing unit (GPU), a field programmable gate array (FPGA), an embedded neural network processor (NPU) or an artificial intelligence (AI) chip. The processor 42 is coupled to the memory 41 and executes the program stored in the memory 41 to execute the distributed digital identity implementation method with custom attributes of real-name authentication of the above-mentioned embodiment 2.

[0078] Further, if Figure 4 As shown, the electronic device may also include: a communication component 43, a power component 44, an audio component 45, a display 46 and other components. Figure 4 Only some components are shown schematically, which does not mean that the electronic device only includes Figure 4 Components shown.

[0079] The communication component 43 is configured to facilitate wired or wireless communication between the electronic device and other devices. The electronic device can access a wireless network based on a communication standard, such as WiFi, 3G, 4G or 5G, or a combination thereof. In an exemplary embodiment, the communication component 43 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 43 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0080] The power supply assembly 44 provides power to various components of the electronic device. The power supply assembly 44 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device.

[0081] The audio component 45 is configured to output and / or input audio signals. For example, the audio component 45 includes a microphone (MIC), and when the electronic device is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 41 or sent via the communication component 43. In some embodiments, the audio component 45 also includes a speaker for outputting audio signals.

[0082] The display 46 includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

[0083] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0084] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A distributed digital identity implementation method with custom attributes for real-name authentication, applied to blockchain, characterized in that: The blockchain includes an access node and a verification node, and the method includes: The access node receives a real-name DID generation request initiated by a user, wherein the real-name DID generation request at least includes the user's identity information encrypted using the public key of the verification node; The verification node performs real-name verification on the user's identity according to the user's identity information sent by the access node; When the real-name verification result is passed, the verification node generates a real-name DID identifier for the user, and generates a real-name DID document of the user according to the real-name DID identifier and the user's public key, wherein the real-name DID document is signed by the verification node using its own private key; The verification node uploads the real-name DID document to the blockchain, wherein the blockchain further includes a business node, and the method further includes: The service node obtains the real-name DID identifier according to the user's identity information; The service node generates a custom real-name DID document according to the user's custom non-real-name DID identifier, the real-name DID identifier, and a custom non-real-name DID document corresponding to the custom non-real-name DID identifier.

2. The method for implementing a distributed digital identity with custom attributes for real-name authentication according to claim 1, characterized in that: After the access node receives the real-name DID generation request initiated by the user, the method further includes: The access node verifies the source of the real-name DID generation request according to the real-name DID generation request; When the verification result indicates that the DID generation request meets the source requirements The access node sends the identity information to the verification node.

3. The method for implementing a distributed digital identity with custom attributes for real-name authentication according to claim 2, characterized in that: The verifying node verifies the identity of the user according to the identity information of the user sent by the access node, including: The verification node uses its private key to decrypt the encrypted identity information to obtain the identity information to be verified; The verification node performs real-name verification on the identity information to be verified based on the user's identity identifier using its own stored identity data to generate the real-name verification result, wherein the real-name verification result indicates that the user's identity identifier and identity information contained in the identity information to be verified are consistent with the identity data stored in the verification node.

4. The method for implementing a distributed digital identity with custom attributes for real-name authentication according to claim 1, characterized in that: The verification node uploading the real-name DID document to the blockchain includes: The verification node uploads the real-name DID document to the blockchain through the real-name DID contract.

5. The method for implementing a distributed digital identity with custom attributes for real-name authentication according to claim 1, characterized in that: The generating of the custom real-name DID document by the service node according to the custom non-real-name DID identifier of the user, the real-name DID identifier, and the custom non-real-name DID document corresponding to the custom non-real-name DID identifier further includes: The access node receives a custom real-name DID generation request sent by the service node, wherein the custom real-name DID generation request includes a custom non-real-name DID identifier and a user's identity identifier; The access node obtains the real-name DID identifier of the user according to the identity identifier of the user; The access node generates a custom real-name DID identifier according to the acquired real-name DID identifier and the custom non-real-name DID identifier; The access node signs the custom real-name DID identifier using its private key to generate a custom real-name DID signature value; The access node sends the custom real-name DID signature value to the service node; The service node writes the custom real-name DID signature value, the custom non-real-name DID identifier, and the real-name DID identifier into a custom non-real-name DID document corresponding to the custom non-real-name DID identifier to generate a custom real-name DID document.

6. The method for implementing a distributed digital identity with custom attributes for real-name authentication according to claim 5, characterized in that: The acquiring, by the access node, of the real-name DID identifier of the user according to the identity identifier of the user comprises: The access node calls the real-name DID contract according to the user's identity identifier to query the real-name DID identifier and the real-name DID document corresponding to the identity identifier; The access node uses the public key of the verification node to perform signature verification on the real-name DID document, and The step of generating, by the access node, a custom real-name DID identifier according to the acquired real-name DID identifier and the custom non-real-name DID identifier comprises: When the signature verification result indicates that the real-name DID document is generated by the verification node, the access node determines whether there is a custom real-name DID signature value corresponding to the custom non-real-name DID identifier; When the access node confirms that there is no custom real-name DID signature value corresponding to the custom non-real-name DID identifier, the access node generates a custom real-name DID identifier based on the acquired real-name DID identifier and the custom non-real-name DID identifier.

7. A distributed digital identity implementation system with custom attributes for real-name authentication, comprising: A service node, an access node and a verification node, wherein the access node and the verification node are deployed on a blockchain, and The service node is used to: send a real-name DID generation request initiated by a user to the access node, wherein the real-name DID generation request at least includes the identity information of the user; The access node is used to: receive the real-name DID generation request sent by the service node, and send the user identity information contained in the real-name DID generation request to the verification node; The verification node is used to: perform real-name verification on the identity of the user according to the identity information of the user sent by the access node; when the real-name verification result is passed, generate a real-name DID identifier for the user, and generate a real-name DID document of the user according to the real-name DID identifier and the user's public key, wherein the real-name DID document is signed by the verification node using its own private key, and the real-name DID document is uploaded to the blockchain. Among them, the business node is further used to: obtain the real-name DID identifier according to the user's identity information; generate a custom real-name DID document according to the user's custom non-real-name DID identifier, the real-name DID identifier, and a custom non-real-name DID document corresponding to the custom non-real-name DID identifier.

8. The distributed digital identity implementation system with custom attributes for real-name authentication according to claim 7, characterized in that: The access node is further used to: receive a custom real-name DID generation request sent by the service node, wherein the custom real-name DID generation request includes a custom non-real-name DID identifier and a user's identity identifier; obtain the user's real-name DID identifier according to the user's identity identifier; generate a custom real-name DID identifier according to the obtained real-name DID identifier and the custom non-real-name DID identifier; sign the custom real-name DID identifier using its private key to generate a custom real-name DID signature value; and send the custom real-name DID signature value to the service node; The business node is further used to write the custom real-name DID signature value, the custom non-real-name DID identifier, and the real-name DID identifier into a custom non-real-name DID document corresponding to the custom non-real-name DID identifier to generate a custom real-name DID document.

9. A computer-readable storage medium having a computer program executable by a processor stored thereon, characterized in that: When the program is executed by a processor, the distributed digital identity implementation method with custom attributes for real-name authentication as described in any one of claims 1 to 6 is implemented.

Images