Anonymous login method and system of digital identity based on real-name authentication and storage medium

Abstract

The application discloses an anonymous login method and system of a digital identity based on real-name authentication and a storage medium. The anonymous login scheme of the digital identity based on real-name authentication disclosed by the embodiment of the application can generate login information by using the user public key in the real-name authentication identity information stored in the real-name digital identity block chain and the login requirements of the target business system, the target business system can obtain the real-name identity information corresponding to the user from the real-name digital identity block chain according to the real-name DID identifier in the login information after receiving the login information, and verify the login information according to the identity information, so that the user can directly log in at the target business system by using the digital identity that has passed the real-name authentication, greatly improving the universality of the real-name DID identity and expanding the application range of the real-name DID identity.

Description

Anonymous login methods, systems, and storage media based on real-name authenticated digital identities Technical Field

[0001] This application relates to the field of network technology, and in particular to an anonymous login method, system, and storage medium based on real-name authentication and digital identity. Background Technology

[0002] With the continuous advancement of trusted technologies, especially blockchain technology, distributed digital identity (DID) application solutions have emerged, bringing revolutionary changes to an increasing number of traditional IT systems. These systems can now leverage distributed digital identities to enable users to exercise self-control over their personal data and assets, and to achieve decentralized data sharing across departments, industries, and regions. Furthermore, as the most authoritative and influential standardization organization in the Web technology field, the World Wide Web Consortium (W3C) launched its first DID standard specification in 2019, marking a significant step forward in the standardization and normalization of DID technology.

[0003] While DID identities have been widely adopted, they are currently typically issued by different blockchains or operators and can only be used on their respective blockchains. This significantly limits the scope of DID applications, especially since verified DID identities require unified authentication by an authoritative institution and cannot be issued by individual platforms. Therefore, although users obtain verified DID identities, they cannot log in and use them on different platforms. To address this, a technical solution is needed that allows users to use verified DID identities when logging into blockchains. Summary of the Invention

[0004] This application provides an anonymous login method, system, and storage medium based on a real-name authenticated digital identity, to address the shortcomings of existing technologies where users cannot log in to different blockchains using a real-name authenticated digital identity.

[0005] To achieve the above objectives, this application provides an anonymous login method based on a real-name authenticated digital identity, used for users to log in to a target business system. The target business system includes a login server connected to a real-name digital identity blockchain, and the method includes:

[0006] The user's client obtains login requirement information from the login server. This login requirement information includes the business system identifier, login access address, and business data of the target business system.

[0007] The client obtains the user's real-name information, wherein the user's real-name information includes the user's real-name DID identifier and at least one user public key;

[0008] The client generates login information based on the user's public key and the login requirement information, and sends it to the login server.

[0009] The login server generates a user authentication request based on the login information and sends it to the real-name digital identity blockchain, wherein the user authentication request contains the user's real-name DID identifier;

[0010] The access node of the real-name digital identity blockchain obtains the user's identity verification information based on the user's real-name DID identifier contained in the user identity verification request;

[0011] The login server verifies the login information using the authentication information and the business data;

[0012] When the verification result is successful, the login server allows the user to log in to the login server using the real-name DID identifier.

[0013] This application also provides an anonymous login system based on a real-name authenticated digital identity, comprising: a target business system and a real-name digital identity blockchain, wherein the target business system includes a login server, and the real-name digital identity blockchain includes access nodes.

[0014] The target business system is used to: send login request information to the user's client, wherein the login request information includes the business system identifier, login access address, and business data of the target business system; receive login information generated by the client based on the user's public key and the login request information, wherein the user's public key includes the user's real-name information obtained by the client, and the user's real-name information also includes the user's real-name DID identifier; generate a user authentication request based on the login information and send it to the real-name digital identity blockchain, wherein the user authentication request includes the user's real-name DID identifier;

[0015] The real-name digital identity blockchain is used to: obtain the user's identity verification information through the access node based on the user's real-name DID identifier contained in the user identity verification request, and send it to the login server of the target business system;

[0016] The target business system is further configured to verify the login information using identity verification information and the business data; and when the verification result is successful, the user is allowed to log in to the login server using the real-name DID identifier.

[0017] This application also provides an electronic device, including:

[0018] Memory, used to store programs;

[0019] A processor is configured to run the program stored in the memory, wherein the program executes the anonymous login method based on real-name authentication digital identity provided in the embodiments of this application.

[0020] This application also provides a computer-readable storage medium storing a computer program executable by a processor, wherein the program, when executed by the processor, implements the anonymous login method based on real-name authentication digital identity as provided in this application.

[0021] The anonymous login method, system, and storage medium based on real-name authentication and digital identity provided in this application embodiment involve the user's client obtaining login requirement information from the login server, acquiring user real-name information including the user's real-name DID identifier and at least one user public key, generating login information based on the user's public key and login requirement information, and sending it to the login server. Therefore, the login server generates a user authentication request based on the login information and sends it to the real-name digital identity blockchain. The real-name digital identity blockchain obtains the user's authentication information based on the user's real-name DID identifier contained in the user authentication request. Thus, the login server can use the authentication information and business data to verify the user's login information, and when the verification result is successful... This allows users to log in using a real-name DID identifier. Therefore, the anonymous login scheme based on real-name authentication digital identity disclosed in this application allows users to generate login information using the user's public key in the real-name authentication identity information stored or obtained on the client and the login requirements of the target business system. After receiving the login information, the target business system can obtain the user's corresponding real-name identity information from the real-name digital identity blockchain according to the real-name DID identifier in the login information, and verify the login information based on the identity information. Thus, users can directly log in to the desired target business system using their already real-name authenticated digital identity, greatly improving the universality of real-name DID identity and expanding the application scope of real-name DID identity.

[0022] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0023] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0024] Figure 1 is a schematic diagram illustrating an application scenario of an anonymous login scheme based on a real-name authenticated digital identity according to an embodiment of this application;

[0025] Figure 2 is a flowchart of an embodiment of the anonymous login method based on real-name authentication digital identity provided in this application;

[0026] Figure 3 is a schematic diagram of the structure of the anonymous login system based on real-name authentication digital identity provided in this application;

[0027] Figure 4 is a schematic diagram of the structure of an embodiment of the electronic device provided in this application. Detailed Implementation

[0028] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0029] Example 1

[0030] The solutions provided in this application can be applied to any data system or server with encryption and decryption functions.

[0031] With the continuous advancement of trusted technologies, especially blockchain technology, distributed digital identity (DID) application solutions have emerged, bringing revolutionary changes to an increasing number of traditional IT systems. These systems can now leverage distributed digital identities to enable users to exercise self-control over their personal data and assets, and to achieve decentralized data sharing across departments, industries, and regions. Furthermore, as the most authoritative and influential standardization organization in the Web technology field, the World Wide Web Consortium (W3C) launched its first DID standard specification in 2019, marking a significant step forward in the standardization and normalization of DID technology.

[0032] In response, the Decentralized Identity (DID) system has been proposed in existing technologies. This system is mainly designed to address the existing centralized identity systems where users' identity information is managed by various websites, and it has been widely adopted. However, currently, DID identities are usually issued by different blockchains or operators and can only be used on their respective blockchains. This greatly limits the application scope of DID identities. In particular, real-name authenticated DID identities need to be uniformly certified by an authoritative institution and cannot be issued by individual platforms. Therefore, although users obtain real-name authenticated DID identities, they cannot log in and use them on different platforms.

[0033] In the current DID system, users can request identity authentication from the DID platform operator. The operator can generate a request based on the user's DID identity to verify the requested identity information. After successful verification, the operator can issue a DID identity to the user, who can then use this DID identity to log in on the platform or the corresponding blockchain. For example, Figure 1 is a schematic diagram illustrating an application scenario of an anonymous login scheme based on a real-name authenticated digital identity according to an embodiment of this application. In the scenario shown in Figure 1, a user can use a DID identity pre-registered on a business system (e.g., a blockchain platform) to log in to the desired business system, for example, by logging into a business node within that system to use its services. When the system supports or requires users to use a real-name DID identity, users can also request a real-name DID identity through various platforms that issue DID identities. However, such real-name DID identities are still issued by each platform after authentication using their respective identity authentication methods or means. They are not universally applicable across different blockchains or business platforms. In actual use, users still need to pre-register multiple DID identities or real-name DID identities and use them on different platforms.

[0034] Therefore, with multiple DID identity operating platforms currently in existence, real-name DID identities generated by different operating platforms are not universally applicable. Even if a user obtains a real-name DID identity from an authoritative institution, they cannot use it on different platforms or blockchains. Instead, they can only use it in the business systems connected to that operating platform. This greatly limits the scope of use of a user's real-name DID identity and also causes inconvenience for users using their real-name DID identity on different business platforms.

[0035] Therefore, according to embodiments of this application, an anonymous login method based on a real-name authenticated digital identity is provided, allowing users to log in to any target business system using a digital identity that has undergone real-name authentication. For example, as shown in Figure 1, which is a schematic diagram illustrating an application scenario of an anonymous login scheme based on a real-name authenticated DID identity according to embodiments of this application. In the scenario shown in Figure 1, in the prior art, when a user wants to use multiple blockchains, they need to request a DID identity in advance from each blockchain or its corresponding operator. The blockchain or its operator can then issue a DID identity to the user after authenticating their identity, and store it in the corresponding blockchain. The user can then log in to that blockchain using the DID identity pre-issued by the target business system. Furthermore, if a user wants to use multiple blockchains, they need to request the issuance of a DID identity on each corresponding blockchain and then use the corresponding DID identity to perform the login operation. Even in situations requiring real-name DID, current technology often involves users authenticating and issuing DIDs through various blockchain platforms. Therefore, users still need to store multiple real-name DID identities for use when logging into different blockchains. For example, in the scenario shown in Figure 1, a user wants to log into one of target business systems 1-3. In current technology, each of these target business systems is built by a different operator, and therefore uses different DID identifiers. Thus, in current technology, the user needs to initiate a DID identifier issuance request on each of the target business systems 1-3. Each target business system can then issue a DID identifier to the user according to its own DID identifier issuance rules based on the submitted request. This allows the user to use the corresponding DID identifier to log in to one or more target business systems. Of course, as mentioned above, an increasing number of blockchains require users to log in with their real names. Therefore, in existing technologies, users request real-name authentication from the corresponding target business system, which then issues a corresponding real-name authentication DID. This means that users still need to use different real-name authentication DIDs when logging into multiple blockchains. Even if a user applies for real-name authentication from an authoritative institution and obtains a real-name authentication DID issued by that institution, since the DID is not issued by the blockchain operator, it is still difficult for the user to use this obtained DID when logging into different blockchains.

[0036] In the embodiments of this application, for example, in the scenario shown in Figure 1, a user can initiate a request to the target business system they wish to log in to via their client to obtain login requirement information. For example, the user can obtain the login requirement information from the login server of the target business system via their client. In this embodiment, the login requirement information may include the business system identifier of the target business system, the login access address (e.g., the address of the login server), and business data, i.e., the business information the user wants to use on the target business system. In this embodiment, the target business system can generate the above-mentioned login requirement information into a QR code and display the QR code on its login page. Users who need to log in to the target business system can then scan the QR code using the corresponding application installed on their client to obtain the login requirement information. Alternatively, in this embodiment, the user can also send a request to the login server of the target business system, including the address of their client in the request. The login server of the target business system can then respond to the request sent by the user via their client and send the login requirement information to the user's client.

[0037] After obtaining the login requirement information, the user can obtain their real-name information through their client, such as a real-name DID identifier issued to the user by an authoritative institution. For example, in this embodiment, the user's real-name information may include the user's real-name DID identifier and at least one user public key. Specifically, in this embodiment, the user can store the real-name DID identifier obtained from the authoritative institution and the corresponding real-name DID document on the client. The user can then directly obtain the locally stored real-name DID identifier through the client and determine a user public key from the corresponding real-name DID document as the public key used for logging into the target business system. Furthermore, the user can obtain the corresponding first private key based on the first public key determined in the DID document.

[0038] Then, the user can generate login information on their client using the obtained user public key and the login requirement information obtained from the target business system. For example, in this embodiment, the user can use an application in the client to calculate the first digest information of the business data contained in the login requirement information using a first algorithm based on the business system identifier of the target business system. For example, after obtaining the login requirement information from the target business system, the user can parse the business system identifier of the target business system from it, and then use a preset first algorithm, such as a hash algorithm, to perform operations on the business data extracted from the login requirement information to obtain the first digest information. Then, the user can use the first private key obtained above to encrypt the first digest information and use the encryption result as the first signature data. Finally, the user can generate login information based on the first signature data, the real-name DID identifier, and the public key information of the first public key, and send it to the login server of the target business system. For example, in this embodiment, the user can encapsulate the first signature data, the real-name DID identifier, and the public key information of the first public key into a data packet, and can further use the public key of the target business system to encrypt the data packet to generate login information. Of course, in the embodiments of this application, the user may also directly put the first signature data, the real-name DID identifier and the public key information of the first public key into a certain data, and then send the data to the login server of the target business system. This application does not restrict this.

[0039] After receiving login information from a user via a client through the login server, the target business system can, for example, first use its private key (which, along with its public key pre-transmitted via broadcast) to decrypt the login information. Then, it can generate an authentication request for the user based on the decrypted login information. For instance, in this embodiment, the target business system can parse the login information sent by the client to extract the user's real-name DID identifier. The target business system can then package this real-name DID identifier and its own business system identifier to generate a user authentication request, which is then sent to the real-name digital identity blockchain. Since in this embodiment, the user can use a real-name DID identifier issued by a professional or authoritative identity authentication authority instead of one generated by the target business system or its operator, the target business system can send the real-name DID identifier contained in the user's login information along with its own business system identifier to the real-name digital identity blockchain after receiving the login information.

[0040] A real-name digital identity blockchain can be any blockchain with real-name identity authentication and verification capabilities, storing the real-name DID identity data of each user. For example, upon receiving a user authentication request from a target business system, an access node of the real-name digital identity blockchain can first obtain the public key of the target business system by using the business system identifier corresponding to the target business system contained in the authentication request. Then, it can use this public key to verify the request, confirming that it originated from the target business system. The real-name digital identity blockchain can then parse the request to obtain the user's real-name DID identifier. The access node can then use this extracted real-name DID identifier to retrieve the stored real-name DID document as authentication information and send this information to the target business system. The target business system's login server can then retrieve the first public key from the real-name DID document obtained from the real-name digital identity blockchain based on the public key information of the first public key obtained above. For example, in this embodiment of the application, the public key information may be the public key index of the first public key in the user's real-name DID document.

[0041] The login server uses the first public key obtained in this way to verify the first signature data in the login information to confirm the signature data. For example, the login server can use a second algorithm, pre-synchronized with the client or specified by the user, to perform similar calculations on the business data to obtain a second digest information (e.g., a hash value) of the business data. The login server can then compare the second digest information obtained in this way with the decrypted signature data. When the second digest information matches the user's decrypted signature data, the verification result is determined to be successful. Therefore, in this embodiment, the user can use a real-name DID identifier not issued by the target business system to log in to the target business system, and the target business system does not need to preset a verification node or server. Instead, it can obtain the corresponding user's real-name DID document from the real-name digital identity blockchain based solely on the real-name DID identifier sent by the user, thereby obtaining the user's public key and verifying the user's real-name DID identity.

[0042] Furthermore, in this embodiment, when a user receives a login request from the target business system, they can check whether they have already stored real-name DID identity information. For example, if the user confirms after checking that they have not yet applied for a real-name DID identity, the user can send a real-name DID identifier application request to the access node of the real-name digital identity blockchain through a client. In this embodiment, the real-name DID identifier application request may at least include the user's identity information and the business system identifier of the target business system; the real-name digital identity blockchain generates a real-name DID identifier and a real-name DID document for the user based on the real-name DID identifier application request, and stores the real-name DID document in the real-name digital identity blockchain, wherein the real-name DID document contains at least a first public key, and then the access node can send the real-name DID identifier and the DID document to the client.

[0043] Furthermore, in this embodiment, when the login server confirms that the user's real-name DID authentication is successful, it can generate a login identifier for the user based on the real-name DID identifier and the business data of the service the user wants to use, allowing the user to log in to the login server using the login identifier. Alternatively, the login server can also directly use the login identifier to log the user in to the login server after generating the login identifier, thereby greatly saving the user's login time.

[0044] The anonymous login scheme based on real-name authentication digital identity provided in this application involves the user's client obtaining login requirement information from the login server. This information includes the user's real-name information (DID) identifier and at least one user public key. Login information is then generated based on the user's public key and the login requirement information and sent to the login server. The login server then generates a user authentication request based on the login information and sends it to the real-name digital identity blockchain. The real-name digital identity blockchain obtains the user's authentication information based on the user's DID identifier included in the authentication request. The login server can then use the authentication information and business data to verify the user's login information. When the verification result is successful, the user is allowed to log in. Users log in using a real-name DID identifier. Therefore, the anonymous login scheme based on real-name authentication digital identity disclosed in this application allows users to generate login information using the user's public key in the real-name authentication identity information stored or obtained on the client and the login requirements of the target business system. After receiving the login information, the target business system can obtain the user's corresponding real-name identity information from the real-name digital identity blockchain according to the real-name DID identifier in the login information, and verify the login information based on the identity information. Thus, users can directly log in to the desired target business system using their already real-name authenticated digital identity, greatly improving the universality of real-name DID identity and expanding the application scope of real-name DID identity.

[0045] The above embodiments illustrate the technical principles and exemplary application framework of the embodiments of this application. The specific technical solutions of the embodiments of this application will be further described in detail below through multiple embodiments.

[0046] Example 2

[0047] Figure 2 is a flowchart of an embodiment of the anonymous login method based on real-name authentication digital identity provided in this application. The executing entity of this method can be various terminal or server devices with data encryption and decryption capabilities deployed on a blockchain, or it can be a device or chip integrated on these devices. Specifically, in this embodiment, 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 authoritative institution. As shown in Figure 2, the anonymous login method based on real-name authentication digital identity includes the following steps:

[0048] S201, the user's client obtains login requirement information from the login server.

[0049] In step S201, the user's client can obtain login requirement information from the login server of the target business system. In this embodiment, the login requirement information may include the business system identifier, login access address, and business data of the target business system. Alternatively, in step S201, the target business system can generate a QR code from the login requirement information and display it on its login page. Users needing to log in to the target business system can scan the QR code using the corresponding application installed on their client in step S201 to obtain the login requirement information. Furthermore, in this embodiment, the user can also send a request to the login server of the target business system in step S201, including their client's address. The login server of the target business system can then respond to the request sent by the user's client and send the login requirement information to the user's client.

[0050] S202, the client obtains the user's real-name information.

[0051] In step S202, the client can obtain the user's real-name information, such as a real-name DID identity identifier issued to the user by an authoritative institution. In this embodiment, the user's real-name information may include the user's real-name DID identifier and at least one user public key. Specifically, in this embodiment, the user can store the real-name DID identifier obtained from the authoritative institution and the corresponding real-name DID document on the client. The client can then directly obtain the locally stored real-name DID identifier and determine a user public key from the corresponding real-name DID document as the public key used by the user to log in to the target business system. Furthermore, the client can obtain the corresponding first private key based on the first public key determined in the DID document.

[0052] S203, the client generates login information based on the user's public key and login requirement information, and sends it to the login server.

[0053] In step S203, the user can generate login information on their client using the user public key obtained in step S202 and the login requirement information obtained from the target business system in step S201. For example, in this embodiment, the user can use an application in the client in step S203 to calculate the first digest information of the business data contained in the login requirement information using a first algorithm based on the business system identifier of the target business system.

[0054] For example, a user can use a preset first algorithm, such as a hash algorithm, to process the business data extracted from the login requirement information to obtain first digest information. Then, the user can use the first private key obtained above to encrypt the first digest information and use the encryption result as first signature data. Finally, the user can generate login information based on the first signature data, the real-name DID identifier, and the public key information of the first public key, and send it to the login server of the target business system. For example, in this embodiment, the user can encapsulate the first signature data, the real-name DID identifier, and the public key information of the first public key into a data packet, and can further use the public key of the target business system to encrypt the data packet, thereby generating login information. Of course, in this embodiment, the user can also directly put the first signature data, the real-name DID identifier, and the public key information of the first public key into some data, and then send the data to the login server of the target business system; this application does not limit this.

[0055] S204 involves the login server generating a user authentication request based on the login information and sending it to the real-name digital identity blockchain.

[0056] In step S204, the login server can parse the login information sent by the user's client and send the generated result as a user authentication request to the real-name digital identity blockchain. After receiving the login information sent by the user through the client via the login server, the target business system can, for example, first use the user's private key, i.e., its public key that has been pre-transmitted via, for example, broadcasting, to decrypt the login information, and then generate an authentication request for the user based on the decrypted login information.

[0057] For example, in this embodiment of the application, the target business system can parse the login information sent by the client in step S202 to extract the user's real-name DID identifier. Then, in step S204, the target business system can package the real-name DID identifier and its own business system identifier to generate a user authentication request so as to send it to the real-name digital identity blockchain.

[0058] In this embodiment of the application, the user can use a real-name DID issued by a professional or authoritative identity authentication authority instead of the real-name DID generated by the target business system or its operator. Therefore, after receiving the login information sent by the user, the target business system can send the real-name DID contained therein, together with its own business system identifier, to the real-name digital identity blockchain.

[0059] S205, the access node of the real-name digital identity blockchain obtains the user's identity verification information based on the user's real-name DID identifier contained in the user identity verification request.

[0060] S206, The login server verifies the login information using authentication information and business data.

[0061] S207, when the verification result is successful, the login server allows the user to log in to the login server using the real-name DID identifier.

[0062] Furthermore, in this embodiment, the real-name digital identity blockchain can be any blockchain with real-name identity authentication and verification capabilities, on which the real-name DID identity data of each user can be stored. For example, after receiving a user authentication request from the target business system in step S204, the access node of the real-name digital identity blockchain can first obtain the public key of the target business system by using the business system identifier corresponding to the target business system contained in the authentication request, and then use the public key to verify the request to determine that the request was sent by the target business system. In step S205, the login server uses authentication information and business data to verify the login information. For example, the real-name digital identity blockchain can parse the request to obtain the user's real-name DID identifier. Then, the access node of the real-name digital identity blockchain can use the extracted real-name DID identifier as authentication information from the real-name DID document stored therein. This authentication information can also be sent to the target business system, whereby the target business system, such as a login server, can retrieve the first public key from the real-name DID document obtained from the real-name digital identity blockchain based on the public key information of the first public key obtained above. For example, in this embodiment, the public key information can be the public key index of the first public key in the user's real-name DID document.

[0063] The login server uses the first public key obtained in this way to verify the first signature data in the login information. For example, the login server can use a second algorithm, pre-synchronized with the client or specified by the user, to perform similar calculations on the business data to obtain a second digest of the business data. The login server can then compare the obtained second digest with the signature data. When the second digest matches the user's signature data, the verification result is considered successful. Therefore, in this embodiment, the user can log in to the target business system using a real-name DID identifier not issued by the target business system. The target business system does not need to preset a verification node or server, but can obtain the corresponding user's real-name DID document from the real-name digital identity blockchain based solely on the real-name DID identifier sent by the user, thereby obtaining the user's public key and verifying the user's real-name DID identity.

[0064] Furthermore, in this embodiment, when a user receives a login request from the target business system, they can check whether they have already stored real-name DID identity information. For example, if the user confirms after checking that they have not yet applied for a real-name DID identity, the user can send a real-name DID identifier application request to the access node of the real-name digital identity blockchain through a client. In this embodiment, the real-name DID identifier application request may at least include the user's identity information and the business system identifier of the target business system; the real-name digital identity blockchain generates a real-name DID identifier and a real-name DID document for the user based on the real-name DID identifier application request, and stores the real-name DID document in the real-name digital identity blockchain, wherein the real-name DID document contains at least a first public key, and then the access node can send the real-name DID identifier and the DID document to the client.

[0065] Furthermore, in this embodiment, when the login server confirms that the user's real-name DID authentication is successful, it can generate a login identifier for the user based on the real-name DID identifier and the business data of the service the user wants to use, allowing the user to log in to the login server using the login identifier. Alternatively, the login server can also directly use the login identifier to log the user in to the login server after generating the login identifier, thereby greatly saving the user's login time.

[0066] The anonymous login method based on real-name authentication digital identity provided in this application involves the user's client obtaining login requirement information from the login server, acquiring user real-name information including the user's real-name DID identifier and at least one user public key, generating login information based on the user's public key and login requirement information, and sending it to the login server. Therefore, the login server generates a user authentication request based on the login information and sends it to the real-name digital identity blockchain. The real-name digital identity blockchain obtains the user's authentication information based on the user's real-name DID identifier included in the user authentication request. Thus, the login server can use the authentication information and business data to verify the user's login information, and when the verification result is successful, allows the user to log in. Users log in using a real-name DID identifier. Therefore, the anonymous login method based on real-name authentication digital identity disclosed in this application allows users to generate login information using the user's public key in the real-name authentication identity information stored or obtained on the client and the login requirements of the target business system. After receiving the login information, the target business system can obtain the user's corresponding real-name identity information from the real-name digital identity blockchain according to the real-name DID identifier in the login information, and verify the login information based on the identity information. Thus, users can directly log in to the desired target business system using their already real-name authenticated digital identity, greatly improving the universality of real-name DID identity and expanding the application scope of real-name DID identity.

[0067] Example 3

[0068] Figure 3 is a schematic diagram of the structure of the anonymous login system based on real-name authentication digital identity provided in this application. This anonymous login system based on real-name authentication digital identity can be used to implement, for example, the anonymous login method based on real-name authentication digital identity provided in the embodiment of this application described with reference to Figure 2.

[0069] In this embodiment, the anonymous login system based on real-name authenticated digital identity may include: a target business system 31, a real-name digital identity blockchain 32, and a user-used client 33. The target business system includes a login server, and the real-name digital identity blockchain includes access nodes.

[0070] The target business system 31 can be used to: send login request information to the user's client 33. The login request information may include the target business system's business system identifier, login access address, and business data; receive login information generated by the client based on the user's public key and the login request information. The user's public key contains the user's real-name information obtained by the client, and the user's real-name information also includes the user's real-name DID identifier; generate a user authentication request based on the login information and send it to the real-name digital identity blockchain. The user authentication request includes the user's real-name DID identifier.

[0071] For example, if a user's client 33 wants to obtain login requirement information from the login server of the target business system 31, in this embodiment, the login requirement information may include the business system identifier, login access address, and business data of the target business system 31. Alternatively, the target business system 31 may generate a QR code from the login requirement information and display it on its login page. Users who need to log in to the target business system can then scan the QR code using the corresponding application installed on their client to obtain the login requirement information. Furthermore, in this embodiment, the user can also send a request to the login server of the target business system, including their client's address in the request. The login server of the target business system can then respond to the request sent by the user through their client and send the login requirement information to the user's client.

[0072] Client 33 can obtain the user's real-name information, such as a real-name DID identity identifier issued to the user by an authoritative institution. In this embodiment, the user's real-name information may include the user's real-name DID identifier and at least one user public key. Specifically, in this embodiment, the user can store the real-name DID identifier obtained from the authoritative institution and the corresponding real-name DID document on client 33. The user can then directly obtain the locally stored real-name DID identifier through client 33 and determine a user public key from the corresponding real-name DID document as the public key used for logging into the target business system. Furthermore, the user can obtain the corresponding first private key based on the first public key determined in the DID document.

[0073] The client generates login information by using the obtained user public key and login requirement information obtained from the target business system 31 through client 33. For example, in this embodiment, the user can use the application in client 33 to calculate the first digest information of the business data contained in the login requirement information based on the business system identifier of the target business system 31 using a first algorithm.

[0074] For example, a user can use a preset first algorithm, such as a hash algorithm, to perform calculations on the business data extracted from the login requirement information to obtain first digest information. Then, the user can use the first private key obtained above to encrypt the first digest information and use the encryption result as first signature data. Finally, the user can generate login information based on the first signature data, the real-name DID identifier, and the public key information of the first public key, and send it to the login server of the target business system 31. For example, in this embodiment, the user can encapsulate the first signature data, the real-name DID identifier, and the public key information of the first public key into a data packet, and can further use the public key of the target business system to encrypt the data packet, thereby generating login information. Of course, in this embodiment, the user can also directly put the first signature data, the real-name DID identifier, and the public key information of the first public key into some data, and then send the data to the login server of the target business system; this application does not limit this.

[0075] The real-name digital identity blockchain 32 can be used to: obtain the user's identity verification information through the user's real-name DID identifier contained in the access node's user identity verification request, and send it to the login server of the target business system 31. The target business system is further used to verify the login information using the identity verification information and the business data; and when the verification result is successful, the user is allowed to log in to the login server using the real-name DID identifier, and the user's client obtains the login requirement information from the login server.

[0076] The login server can parse the login information sent by the user's client 33 and send the generated result as a user authentication request to the real-name digital identity blockchain. After receiving the login information sent by the user through client 33 via the login server, the target business system 31 can, for example, first use the user's private key, i.e., its public key that has been pre-transmitted via, for example, broadcasting, to decrypt the login information, and then generate an authentication request for the user based on the decrypted login information.

[0077] For example, in this embodiment of the application, the target business system 31 can parse the login information sent by the client 33 to extract the user's real-name DID identifier. Then, the target business system can package the real-name DID identifier and its own business system identifier to generate a user authentication request, so as to send it to the real-name digital identity blockchain.

[0078] In this embodiment of the application, the user can use a real-name DID issued by a professional or authoritative identity authentication authority instead of the real-name DID generated by the target business system or its operator. Therefore, after receiving the login information sent by the user, the target business system can send the real-name DID contained therein, together with its own business system identifier, to the real-name digital identity blockchain.

[0079] The real-name digital identity blockchain 32 can be any blockchain with real-name identity authentication and verification capabilities, on which real-name DID identity data of each user can be stored. For example, after receiving a user authentication request from a target business system, the access node of the real-name digital identity blockchain can first obtain the public key of the target business system by using the business system identifier corresponding to the target business system contained in the authentication request, and then use the public key to verify the request to determine that the request was sent by the target business system. The login server uses authentication information and business data to verify the login information. For example, the real-name digital identity blockchain can parse the request to obtain the user's real-name DID identifier. Then, the access node of the real-name digital identity blockchain can use the extracted real-name DID identifier to retrieve the real-name DID document stored therein as authentication information, and can also send the obtained authentication information to the target business system 31. Thus, the login server of the target business system 31 can obtain the first public key from the real-name DID document obtained by the real-name digital identity blockchain 32 based on the public key information of the first public key obtained above. For example, in this embodiment of the application, the public key information may be the public key index of the first public key in the user's real-name DID document.

[0080] The target business system 31 can use the first public key obtained in this way to verify the first signature data in the login information. For example, the login server of the target business system 31 can use a second algorithm, pre-synchronized with the client or specified by the user, to perform similar calculations on the business data to obtain the second digest information of the business data. Then the login server can compare the second digest information obtained in this way with the signature data. When the second digest information matches the user's signature data, the verification result is determined to be successful. Therefore, in this embodiment, the user can log in to the target business system using a real-name DID identifier not issued by the target business system, and the target business system 31 does not need to preset a verification node or server. Instead, it can obtain the corresponding user's real-name DID document from the real-name digital identity blockchain based solely on the real-name DID identifier sent by the user, thereby obtaining the user's public key and verifying the user's real-name DID identity.

[0081] Furthermore, in this embodiment, when a user receives a login request from the target business system, they can check whether they have already stored real-name DID identity information. For example, if the user confirms after checking that they have not yet applied for a real-name DID identity, the user can send a real-name DID identifier application request to the access node of the real-name digital identity blockchain through a client. In this embodiment, the real-name DID identifier application request may at least include the user's identity information and the business system identifier of the target business system; the real-name digital identity blockchain generates a real-name DID identifier and a real-name DID document for the user based on the real-name DID identifier application request, and stores the real-name DID document in the real-name digital identity blockchain, wherein the real-name DID document contains at least a first public key, and then the access node can send the real-name DID identifier and the DID document to the client.

[0082] The anonymous login system based on real-name authentication and digital identity provided in this application involves the user's client obtaining login requirement information from the login server. This information includes the user's real-name DID identifier and at least one user public key. Login information is then generated based on the user's public key and the login requirement information and sent to the login server. The login server then generates a user authentication request based on the login information and sends it to the real-name digital identity blockchain. The real-name digital identity blockchain obtains the user's authentication information based on the user's real-name DID identifier included in the authentication request. The login server can then use the authentication information and business data to verify the user's login information. When the verification result is successful, the user is allowed to log in. Users log in using a real-name DID identifier. Therefore, in the anonymous login system based on real-name authentication digital identity disclosed in this application embodiment, users can generate login information using the user's public key in the real-name authentication identity information stored or obtained on the client and the login requirements of the target business system. After receiving the login information, the target business system can obtain the user's corresponding real-name identity information from the real-name digital identity blockchain according to the real-name DID identifier in the login information, and verify the login information based on the identity information. Thus, users can directly log in to the desired target business system using their already real-name authenticated digital identity, greatly improving the universality of real-name DID identity and expanding the application scope of real-name DID identity.

[0083] Example 4

[0084] The above describes the internal functions and structure of an anonymous login system based on real-name authentication and digital identity, which can be implemented as an electronic device. Figure 4 is a schematic diagram of the structure of an embodiment of the electronic device provided in this application. As shown in Figure 4, the electronic device includes a memory 41 and a processor 42.

[0085] Memory 41 is used to store programs. In addition to the programs described above, memory 41 can also be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, contact data, phonebook data, messages, pictures, videos, etc.

[0086] 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 storage, flash memory, magnetic disk or optical disk.

[0087] Processor 42 is not limited to a processor (CPU), but may also be a graphics processing unit (GPU), a field-programmable gate array (FPGA), an embedded neural network processor (NPU), or an artificial intelligence (AI) chip. Processor 42 is coupled to memory 41 and executes the program stored in memory 41 to perform the anonymous login method based on real-name authentication digital identity described in Embodiment 2 above.

[0088] Furthermore, as shown in Figure 4, the electronic device may also include other components such as a communication component 43, a power supply component 44, an audio component 45, and a display 46. Figure 4 only schematically illustrates some components and does not imply that the electronic device includes only the components shown in Figure 4.

[0089] Communication component 43 is configured to facilitate wired or wireless communication between electronic devices and other devices. The electronic devices can access wireless networks based on communication standards, such as WiFi, 3G, 4G, or 5G, or combinations thereof. In one exemplary embodiment, communication component 43 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 43 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0090] Power supply component 44 provides power to various components of the electronic device. Power supply component 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.

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

[0092] 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 can be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation.

[0093] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0094] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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 or all of the technical features; and these modifications or substitutions 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. An anonymous login method based on real-name authentication digital identity, used for users to log in to a target business system, characterized in that, The target business system includes a login server connected to a real-name digital identity blockchain, and the method includes: a user's client obtaining login requirement information from the login server, wherein the login requirement information includes the business system identifier, login access address, and business data of the target business system; the client obtaining user real-name information, wherein the user real-name information includes the user's real-name DID identifier and at least one user public key; the client generating login information based on the user public key and the login requirement information, and sending it to the login server; the login server generating a user authentication request based on the login information and sending it to the real-name digital identity blockchain, wherein the user authentication request includes the user's real-name DID identifier; an access node of the real-name digital identity blockchain retrieving the user's authentication information DID document stored therein based on the user's real-name DID identifier included in the user authentication request; and the login server using the authentication information DID document. The login information is verified using the business data. When the verification result is successful, the login server allows the user to log in to the login server using the real-name DID identifier. The step of the client obtaining the user's real-name information includes: the client obtaining the user's first real-name DID document based on the user's identity identifier; the client obtaining a first public key from at least one public key in the first real-name DID document; and the client obtaining a first private key based on the first public key. The step of the client generating login information based on the user's public key and the login requirement information includes: the client calculating a first digest of the business data contained in the login requirement information using a first algorithm based on the business system identifier of the target business system; the client encrypting the digest information using the first private key to generate first signature data; and the client generating the login information using the first signature data, the real-name DID identifier, and the public key information of the first public key.

2. The anonymous login method based on real-name authentication digital identity according to claim 1, characterized in that, The step of the login server generating a user authentication request based on the login information includes: the login server obtaining the real-name DID identifier from the login information; and the login server using the real-name DID identifier and the business system identifier of the target business system as the user authentication request.

3. The anonymous login method based on real-name authentication digital identity according to claim 2, characterized in that, The step of retrieving the user's identity verification information DID document stored therein by the access node of the real-name digital identity blockchain based on the user's real-name DID identifier included in the user identity verification request includes: the access node of the real-name digital identity blockchain obtaining a real-name DID document corresponding to the real-name DID identifier from the real-name digital identity blockchain as the identity verification information DID document.

4. The anonymous login method based on real-name authentication digital identity according to claim 3, characterized in that, The verification of the login information by the login server using the authentication information DID document and the business data includes: the login server obtaining the first public key from the real-name DID document based on the public key information of the first public key; the login server decrypting the first signature data in the login information using the first public key to obtain decrypted signature data; the login server performing calculation processing on the business data according to a second algorithm corresponding to the business data to obtain second digest information of the business data; and the login server comparing the second digest information with the decrypted signature data, and determining that the verification result is successful when the second digest information matches the decrypted signature data.

5. The anonymous login method based on real-name authentication digital identity according to claim 1, characterized in that, Before the client obtains the user's real-name information corresponding to the target business system based on the login requirements of the target business system, the method further includes: the client sending a real-name DID identifier application request to the access node of the real-name digital identity blockchain, wherein the real-name DID identifier application request contains at least the user's identity information; the real-name digital identity blockchain generating a real-name DID identifier and a real-name DID document for the user based on the real-name DID identifier application request, and storing the real-name DID document in the real-name digital identity blockchain, wherein the real-name DID document contains at least a first public key; and the access node sending the real-name DID identifier and the real-name DID document to the client.

6. The anonymous login method based on real-name authentication digital identity according to claim 1, characterized in that, The login server allows the user to log in to the login server using the real-name DID identifier by: the login server generating the user's login identifier based on the real-name DID identifier and the business data, so as to allow the user to log in to the login server using the login identifier.

7. A login system based on real-name authentication and digital identity, comprising: The system comprises a target business system, a real-name digital identity blockchain, and a client used by the user. The target business system includes a login server, and the real-name digital identity blockchain includes access nodes. The target business system is characterized by: sending login request information to the user's client, wherein the login request information includes the target business system's business system identifier, login access address, and business data; and receiving login information generated by the client based on the user's public key and the login request information, wherein the user's public key includes the user's real-name information obtained by the client, and the user's real-name information also includes the user's real-name DID identifier. The client generates a user authentication request based on the login information and sends it to the real-name digital identity blockchain, wherein the user authentication request includes the user's real-name DID identifier; the client is configured to: obtain login requirement information from the login server, wherein the login requirement information includes the business system identifier, login access address, and business data of the target business system; obtain user real-name information, wherein the user real-name information includes the user's real-name DID identifier and at least one user public key; generate login information based on the user public key and the login requirement information, and send it to the login server; the real-name digital identity blockchain is configured to: [follow the login request information] The ingress node retrieves the user's authentication information DID document stored therein based on the user's real-name DID identifier included in the user authentication request, and sends it to the login server of the target business system. The target business system further verifies the login information using the authentication information DID document and the business data. When the verification result is successful, the user is allowed to log in to the login server using the real-name DID identifier. The steps for the client to obtain the user's real-name information include: the client obtaining the user's first real-name DID document based on the user's identity identifier; the client obtaining a first public key from at least one public key in the first real-name DID document; the client obtaining a first private key based on the first public key; and the steps for the client to generate login information based on the user's public key and the login requirement information include: the client calculating a first digest of the business data included in the login requirement information using a first algorithm based on the business system identifier of the target business system; the client encrypting the digest information using the first private key to generate first signature data; and the client generating the login information using the first signature data, the real-name DID identifier, and the public key information of the first public key.

8. A computer-readable storage medium having a computer program stored thereon that can be executed by a processor, characterized in that, When the program is executed by the processor, it implements the anonymous login method based on real-name authentication digital identity as described in any one of claims 1 to 6.

Images