Diversified registration method and device based on DID credential data storage, electronic device and storage medium

Abstract

The present application discloses a diversified registration method and device, electronic device and storage medium based on a DID credential data storage area. The method comprises: receiving a user registration request sent by a user node, wherein the registration request contains user information; determining the registration type of the user according to the user information; retrieving registered information matching the user information from the registered information corresponding to the registration type; when the search result is that there is no registered information matching the user information, generating the registration information of the user according to the user information. The embodiment of the present application ensures the security of user registration while providing users with a flexible registration method.

Description

Technical Field

[0001] The present application relates to the field of network technology, and in particular to a diversified registration method and device, an electronic device and a storage medium based on a DID credential data storage area. Background Art

[0002] 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 anonymity of the Internet, websites often cannot know the true identity of users who visit or log in to their websites, and therefore cannot regulate and manage the use of services by users accordingly. To this end, the prior art has proposed that users need to pre-register their identity information in the website they visit or log in to, so that the website can provide services to users based on the identity information submitted by the user when the user requests to use the website's services. In this process, the user needs to provide the original data of his or her identity information to the website and then save it in the website's server, but such identity information is usually the user's private data. Therefore, when the user uses the services provided by different websites, he or she has to store his or her private data on each website, which greatly increases the risk of user privacy exposure. In response to this, the prior art proposes to establish an additional DID (decentralized identity identification) system, in which the user can request the second party with identity authentication capabilities to issue the relevant certificate of the identity information required by the user, and the user provides the certificate to the user to replace the solution in the prior art that the user needs to save the original identity information on the user's website. However, in this solution, users need to pre-register in the DID system before using it, so a technical solution is needed that can facilitate users to quickly and securely register in the DID system. Summary of the invention

[0003] The embodiments of the present application provide a diversified registration method and device, an electronic device, and a storage medium based on a DID credential data storage area to solve the defects in the prior art that it is inconvenient for users to register in a DID system and there are security risks.

[0004] To achieve the above objectives, the present application embodiment provides a diversified registration method based on a DID credential data storage area, including:

[0005] Receiving a user registration request sent by a user node, wherein the registration request includes user information;

[0006] Determining the registration type of the user according to the user information;

[0007] Retrieving registered information matching the user information from the registered information corresponding to the registration type;

[0008] When the search result is that there is no registered information matching the user information, the registration information of the user is generated according to the user information.

[0009] The embodiment of the present application also provides a diversified registration device based on a DID credential data storage area, including:

[0010] A receiving module, configured to receive a user registration request sent by a user node, wherein the registration request includes user information;

[0011] A determination module, used to determine the registration type of the user according to the user information;

[0012] A retrieval module, used to retrieve the registered information matching the user information from the registered information corresponding to the registration type;

[0013] A generating module is used to generate the registration information of the user according to the user information when the search result shows that there is no registered information matching the user information.

[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 running, the diversified registration method based on DID credential data provided in the 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, a diversified registration method based on a DID credential data storage area as provided in an embodiment of the present application is implemented.

[0018] The diversified registration method and device, electronic device and storage medium based on the DID credential data storage area provided in the embodiments of the present application determine the registration type of the user registration based on the user information in the user's registration request sent by the user node, and search whether there is registered information matching the user information in the registered information corresponding to the registration type. When there is no matching registered information, the registration information of the user can be generated based on the user information. Therefore, the user can use various types of user information as their registration information in the DID system, and can avoid duplication of user registration information by querying whether there is registered information matching the user information in the registered information of the corresponding type, thereby ensuring the security of user registration while providing users with a flexible registration method.

[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 is a schematic diagram showing an application scenario of a diversified registration solution based on a DID credential data storage area according to an embodiment of the present application;

[0022] Figure 2 A flowchart of an embodiment of the diversified registration method provided by the present application;

[0023] Figure 3 A schematic diagram of the structure of the diversified registration device provided for this application;

[0024] Figure 4 A 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 with user information processing function.

[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 anonymity of the Internet, websites often cannot know the true identity of users who visit or log in to their websites, and therefore cannot regulate and manage the use of services by users accordingly. To this end, the prior art has proposed that users need to pre-register their identity information in the website they visit or log in to, so that the website can provide services to users based on the identity information submitted by the user when the user requests to use the website's services. In this process, the user needs to provide the original data of his or her identity information to the website and then save it in the website's server, but such identity information is usually the user's private data. Therefore, when the user uses the services provided by different websites, he or she has to store his or her private data on each website, which greatly increases the risk of user privacy exposure. In response to this, the prior art proposes to establish an additional DID (decentralized identity identification) system, in which the user can request the second party with identity authentication capabilities to issue the relevant certificate of the identity information required by the user, and the user provides the certificate to the user to replace the solution in the prior art that the user needs to save the original identity information on the user's website.

[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 issuer that is capable of authenticating the user's real identity, and the issuer can verify the identity information requested by the user based on the user's authentication request and issue credential data to the user after the verification is passed. The credential data can be used as proof data issued by an authority to the user to prove the user's specific identity information. For example, Figure 1 Schematic diagram showing an application scenario of a diversified registration solution based on a DID credential data storage area according to an embodiment of the present application. Figure 1In the scenario shown in , a user can use a terminal with an application of the DID system installed to access the DID system through a user node and send a registration request to a service node. In an embodiment of the present application, a service node in a DID system may be a node for storing user information and user credential data issued by, for example, a department or unit that is legally or recognized as being able to authenticate one or more identity information of a user, and in the service node, the user's credential data is encrypted and stored, for example, using the user's own user public key, so that in the DID system, only the user who has the user private key corresponding to the user public key can access the credential data stored on the service node, or the user establishes authorization information for a third party, for example, a user, in the service node, so that the third party can access the credential data in the service node that is authorized by the user to access.

[0031] To this end, the user first needs to register in the DID system so that the user's registration information can be uniquely identified by the system. Figure 1 In the scenario shown in , the user can send a registration request to the service node, which can include the user's user information, to request the service node to create a user identity for the user in the DID system according to the registration request, so that the user can store the credential data in the service node and manage the credential data and the credential key used to encrypt the credential data through the service node. However, in actual use, since users who use the DID system are often users of other platforms or systems, they use the DID system only to show their identity information to the user through one or more credential data issued by the issuer, so as to avoid leaking their identity information in the platform or system where the user actually uses various services. Therefore, the users of the DID system do not really want to operate or request services in the DID system. On the contrary, the users use the DID system for use in other systems or platforms. For this reason, although users need to pre-register in the DID system before they can use the system, if the user needs to record the user identity in the DID system, such as the account name or the nickname in the system, due to the registration requirements of the DID system for the user, it will undoubtedly greatly increase the inconvenience of the user. In this case, users not only need to remember the account information they use on other platforms on the Internet, but also need to remember the account information registered in the DID system according to system requirements.

[0032] To this end, according to the diversified registration method of the embodiment of the present application, the user information in the registration request sent by the user can include the name identifier that the user wants to use in the DID system and the description information of the name identifier, so that the service node can understand the information related to the name identifier based on the description information, and thus process the name identifier accordingly. In other words, the diversified registration method of the embodiment of the present application has no restrictions on what user information the user uses to register. The user only needs to include the name identifier that he wants to use and the description of the name identifier in the user information in the registration request.

[0033] For example, a user can use an account name that has been registered and used on a third-party website or platform as the name identifier included in the user information in the registration request. For example, when a user visits a game platform or website operated by a third party to request to use the game service provided by it, the platform or website requires that the user's age is equal to or over 18 years old on the date when the user visits the game platform or website to request to use the game service provided by it. To this end, in the traditional prior art, the user needs to fill in his or her date of birth and other information on the game platform or website operated by the third party, and upload a legally valid identity document so that the game platform or website operated by the third party can verify the user's user information. However, as mentioned above, such prior art will cause the user's identity information to be stored on various websites or platforms, thereby bringing great risks of privacy leakage. Users of the DID system of the embodiment of the present application can ask the gaming platform or website operated by a third party to require the user to be 18 years old or older to use the gaming service, and request the authentication party in the DID system to issue credential data for the user's age when accessing the gaming platform. The issuing party can send the credential data to the service node, so that the service node can store the credential data in its storage space and encrypt it. The user can notify the user to obtain the credential data from the service node, so that the user can confirm that the user can use the gaming service provided on its website or platform based on the credential data.

[0034] Therefore, for such users, they may want to use the account name that they have registered and used on the game platform or website they frequently visit as their name identifier in the DID system. In this way, not only do users not need to record the name representation of the special user DID system, but the third party that operates the game platform or website visited by the user can also directly request the user's credential data from the user or service node in the DID system based on the account name registered by the user on its platform.

[0035] When a user wishes to register in the DID system using an account name registered on, for example, a game platform or website, if the user only fills in the account name when submitting a registration request to the service node in the DID system, the DID system cannot actually identify the association between the account name and the third-party website, for example, it cannot confirm whether the account name is the account name used on the third-party website. Therefore, the user can further include a description of the account name in the user information in the registration application sent by the user, for example, the name or URL of the game website where the account name is registered. Therefore, the service node can understand from the description information that the type of registration identification the user wants to use is the type of registration using a third-party account, and can send account name verification information to the website based on the URL of the website operated by the third party recorded in the description information, so as to request the website operated by the third party to confirm whether the account name included in the registration request sent by the user to the service node in the DID system is the account name used on the website. When the website operated by the third party confirms that the account name submitted by the user to the service node in the DID system is indeed the account name registered and used on its website according to the verification information of the service node, the service node can generate a registration identifier for registration in the DID system according to the registration identifier, that is, the account name, included in the user's registration information, and the third-party information included in the description, such as the website name, or the company name of the third party, etc. For example, in an embodiment of the present application, the service node can use the account name included in the registration request of the user as part of the candidate registration identifier, and the company name or the name of the website operated by the third party included in the description information as part of the candidate registration identifier, and the registration type of the user registered previously confirmed according to the description information is also used as part of the candidate registration identifier, so that a candidate registration identifier for registration in the DID system can be generated. Here, since the service node cannot yet determine whether there are duplicate user accounts registered in it, it is not possible to directly use the candidate registration identifier generated in this way as the registration information used by the user to identify himself in the DID system.

[0036] The service node can search for the candidate registration identifier under the third-party account registration type already stored on the service node based on the candidate registration identifier generated as above, for example, by comparing all registered information under the third-party account registration type stored in the service node with the candidate registration identifier it claims to confirm whether there is a candidate registration identifier of the third-party account registration type that has been registered by others in the DID system.

[0037] When the above search result indicates that there is no registration identifier generated according to the user information in the user's registration request, the service node may use the generated candidate registration identifier as the registration identifier of the user.

[0038] After the service node generates a registration identifier according to the third-party account name specified by the user, the service node needs to use the user's public key to encrypt the user's credential data. For example, when receiving the user's credential data, the service node can generate a credential key for each credential data to encrypt the credential data, and then use the user's public key to encrypt the credential key, so that the credential data stored in the service node cannot be accessed and read by others without the user's private key, ensuring the security of the user's privacy data. To this end, the service node can send a registration response message to the user after determining the registration identifier for the user, and include the registration information generated for the user and the user public key acquisition request for the user's public key in the response message, so that after receiving the response message, the user can use his own terminal or use the user node to generate his own public key private key pair, and associate it with the registration identifier received from the service node, and then send the public key in the generated public key private key pair to the service node, so that after receiving the user's public key, the service node can store the user's public key in association with the registration information previously generated for the user.

[0039] In addition, the user may not use an existing account name, such as one used in a third-party platform or system, but may use an account name that he or she has created as the name identifier included in the user information in the registration request. For example, the user may wish to use a separate account name for the DID system so that other people or malicious third parties cannot easily guess the user identifier used in the DID system from the account name used on the public platform.

[0040] Therefore, for such a user, the user can include the account name he created by himself in the registration request he sent, and can further use words such as custom as a description of the account name, so that the service node can determine from the description that the type of registration identifier the user wants to use is a type registered using a custom account name, and can generate a registration identifier for registration in the DID system based on the registration identifier, that is, the account name, included in the user's registration information, and the identification code or information for the custom account name pre-set in the DID system. For example, in an embodiment of the present application, the service node can use the account name included in the registration request of the user as part of the candidate registration identifier, and the identification code of the custom registration pre-set in the system as part of the candidate registration identifier, and the registration type of the user registration previously confirmed according to the description information is also used as part of the candidate registration identifier, so that a candidate registration identifier for registration in the DID system can be generated. Here, since the service node cannot yet determine whether there are duplicate user accounts registered in it, it is not yet possible to directly use the candidate registration identifier generated in this way as the registration information used by the user to identify himself in the DID system.

[0041] The service node can search for the candidate registration identifier under the custom account registration type already stored on the service node based on the candidate registration identifier generated as above, for example, by comparing all registered information under the custom account registration type stored in the service node with the candidate registration identifier it claims to confirm whether there is a candidate registration identifier of the custom account registration type that has been registered by others in the DID system.

[0042] When the above search result indicates that there is no registration identifier generated according to the user information in the user's registration request, the service node may use the generated candidate registration identifier as the registration identifier of the user.

[0043] After the service node generates a registration identifier based on the account name created by the user, the service node needs to use the user's public key to encrypt the user's credential data. For example, when receiving the user's credential data, the service node can generate a credential key for each credential data to encrypt the credential data, and then use the user's public key to encrypt the credential key, so that the credential data stored in the service node cannot be accessed and read by others without the user's private key, ensuring the security of the user's privacy data. To this end, the service node can send a registration response message to the user after determining the registration identifier for the user, and include the registration information generated for the user and the user public key acquisition request for the user's public key in the response message, so that after receiving the response message, the user can use his own terminal or use the user node to generate his own public key and private key pair, and associate it with the registration identifier received from the service node, and then send the public key in the generated public key and private key pair to the service node, so that after receiving the user's public key, the service node can store the user's public key in association with the registration information previously generated for the user.

[0044] In addition, the user can also directly use the user public key generated by using his terminal or user node as the name identifier contained in the user information in the registration request. In other words, the service node needs to use the user's public key to encrypt the user's credential data. For example, when receiving the user's credential data, the service node can generate a credential key for each credential data to encrypt the credential data, and then use the user's public key to encrypt the credential key, so that the credential data stored in the service node cannot be accessed and read by others without the user's private key, ensuring the security of the user's privacy data. Therefore, the user can directly use the user public key as the name identifier in the DID system, so that the user does not need to record the name identifier of the special user DID system separately, but only needs to use his user public key as the unique identifier in the DID system to send various requests to the service node or other nodes in the DID system each time.

[0045] Therefore, the user may further include a description of the account name in the user information in the registration application sent by the user, for example, it may be a predetermined descriptive term such as "user public key". Therefore, the service node can understand from the descriptive information that the type of registration identification the user wants to use is the type registered using the user's user public key. The service node can search for the user public key under the stored user public key registration type, for example, compare all the registered information under the user public key registration type stored in the service node with the user public key sent by the user to confirm whether there is a user public key of the user public key registration type that has been registered by others in the DID system.

[0046] When the above search result indicates that the user public key in the user's registration request does not exist, the service node may use the user public key as the registration identifier of the user.

[0047] In this case, the user's registration identifier in the DID system is the user's public key used by the service node to encrypt the user's credential key. Therefore, after the service node uses the user's public key as the user's registration identifier as above, it is no longer necessary to request the user to send the user's public key separately. Instead, the service node can only include the user's public key as registered information in the registration response information sent to the user, and can further include registration status information such as successful registration.

[0048] The diversified registration scheme based on the DID credential data storage area provided in the embodiment of the present application determines the registration type of the user registration based on the user information in the user's registration request sent by the user node, and searches the registered information corresponding to the registration type to see whether there is registered information matching the user information. When there is no matching registered information, the registration information of the user can be generated based on the user information. Therefore, the user can use various types of user information as their registration information in the DID system, and can avoid duplication of user registration information by querying whether there is registered information matching the user information in the registered information of the corresponding type, thereby ensuring the security of user registration while providing users with a flexible registration method.

[0049] 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.

[0050] Embodiment 2

[0051] Figure 2This is a flowchart of an embodiment of a diversified registration method based on a DID credential data storage area provided by this application. The execution subject of this method can be various terminals or server devices with data processing, or it can be a device or chip integrated on these devices. Figure 2 As shown, the diversified registration method includes the following steps:

[0052] S201, receiving a user registration request sent by a user node.

[0053] In step S201, the service node in the DID system may receive a registration request sent by the user through the user node. In an embodiment of the present application, the service node in the DID system may be a node for storing user information and user credential data issued by, for example, a department or unit that is legally or recognized as being able to authenticate one or more identity information of the user, and in the service node, the user's credential data is encrypted and stored, for example, using the user's own user public key, so that in the DID system, only the user who has the user's private key corresponding to the user's public key can access the credential data stored on the service node, or the user establishes authorization information for a third party, for example, a user, in the service node, so that the third party can access the credential data in the service node that is authorized by the user to access. Therefore, the user needs to register in the DID system so that the user's registration information can be uniquely identified by the system in the system.

[0054] The registration request received in step S201 may include user information of the user, so that, for example, the service node may create a user identifier for the user in the DID system based on the registration request, so that the user can store credential data in the service node and manage the credential data and the credential key used to encrypt the credential data through the service node.

[0055] S202: Determine the user's registration type according to the user information.

[0056] In step S202, the service node can first determine the user's registration type based on the user information in the registration request received in step S201. In actual use, since users using the DID system are often users of other platforms or systems, they use the DID system only to present their identity information to the user through one or more credential data issued by the issuer, thereby avoiding the disclosure of their identity information in the platform or system where the user actually uses various services. Therefore, the user of the DID system does not really want to operate or request services in the DID system. Users use the DID system to present their identity certificates in other systems or platforms. For this reason, although users need to pre-register in the DID system before they can use the system, if the user needs to record the user identification in the DID system, such as the account name or the nickname in the system, etc., due to the registration requirements of the DID system for users, it will undoubtedly greatly increase the inconvenience of the user. In this case, the user not only needs to remember the account information used on other platforms on the Internet, but also needs to remember the account information registered in the DID system according to the system requirements.

[0057] To this end, in step S201, in the registration request sent by the user, the user information may include the name identifier that the user wants to use in the DID system and the description information of the name identifier, so that the service node can understand the information related to the name identifier according to the description information in step S202, and thus process the name identifier accordingly. In other words, the diversified registration method of the embodiment of the present application has no restrictions on what user information the user uses to register. The user only needs to include the name identifier that he wants to use and the description of the name identifier in the user information in the registration request.

[0058] S203: Retrieve registered information matching the user information from the registered information corresponding to the registration type.

[0059] S204: When the search result shows that there is no registered information matching the user information, the registration information of the user is generated according to the user information.

[0060] In step S203, after the service node determines the type of account that the user wants to register based on the user information in the registration request received in step S201, it can first search in step S203 whether there is registered information matching the user information that the user wants to register in the registered information corresponding to the registration type stored in the service node to ensure that the user can have a unique identification in the DID system. Therefore, in step S204, when the search result in step S203 indicates that there is no registered information matching the user information that the user wants to register, it means that the user information received in step S201 has not been registered for use by other users in the current DID system.

[0061] For example, the name identifier of the user information received in step S201 can be the account name that the user has registered and used on a third-party website or platform. For example, when a user visits a game platform or website operated by a third party to request to use the game service provided by it, the platform or website requires that the user's age is equal to or exceeds 18 years old on the date when the user visits the game platform or website to request to use the game service provided by it. For this reason, in the traditional prior art, the user needs to fill in his or her date of birth and other information on the game platform or website operated by the third party, and upload a legally binding identity document so that the game platform or website operated by the third party can check the user information of the user. However, as mentioned above, such prior art will cause the user's identity information to be stored on each website or platform, thereby bringing great privacy leakage risks. Users of the DID system of the embodiment of the present application can ask the gaming platform or website operated by a third party to require the user to be 18 years old or older to use the gaming service, and request the authentication party in the DID system to issue credential data for the user's age when accessing the gaming platform. The issuing party can send the credential data to the service node, so that the service node can store the credential data in its storage space and encrypt it. The user can notify the user to obtain the credential data from the service node, so that the user can confirm that the user can use the gaming service provided on its website or platform based on the credential data.

[0062] Therefore, for such users, they may want to use the account name that they have registered and used on the game platform or website they frequently visit as their name identifier in the DID system. In this way, not only do users not need to record the name representation of the special user DID system, but the third party that operates the game platform or website visited by the user can also directly request the user's credential data from the user or service node in the DID system based on the account name registered by the user on its platform.

[0063] In addition, in the case where the user uses a third-party account name, the user information received in step S201 may further include a description of the account name, for example, the name or URL of the game website to which the account name is registered. Therefore, in step S202, the service node can understand from the description information that the type of registration identifier that the user wants to use is a type of registration using a third-party account, and in step S203, the service node can send account name verification information to the website based on the URL of the website operated by the third party recorded in the description information, so as to request the website operated by the third party to confirm whether the account name included in the registration request sent by the user to the service node in the DID system is the account name used by the user on the website. If the website operated by the third party confirms that the account name submitted by the user to the service node in the DID system is indeed the account name registered and used on its website based on the verification information of the service node, the service node can generate a registration identifier for registration in the DID system based on the registration identifier, i.e., the account name, included in the registration information of the user, and the third-party information included in the description, such as the website name, or the company name of the third party, etc.

[0064] For example, in an embodiment of the present application, the service node may use the account name included in the registration request of the user as part of the candidate registration identifier, and use the company name or operating website name of the third party included in the description information as part of the candidate registration identifier, and use the registration type of the user registration previously confirmed based on the description information as part of the candidate registration identifier, thereby generating a candidate registration identifier for registration in the DID system.

[0065] Next, the candidate registration identifier generated as above can be used to search for the candidate registration identifier under the third-party account registration type already stored on the service node. For example, all registered information under the third-party account registration type stored in the service node can be compared with the candidate registration identifier it claims to confirm whether there is a candidate registration identifier of the third-party account registration type that has been registered by others in the DID system.

[0066] When the above search result indicates that there is no registration identifier generated according to the user information in the user's registration request, the service node may use the generated candidate registration identifier as the registration identifier of the user in step S204.

[0067] In addition, after the registration identifier is generated according to the third-party account name specified by the user in step S204, since the service node needs to use the user's public key to encrypt the user's credential data, for example, the service node can generate a credential key for each credential data to encrypt the credential data when receiving the user's credential data, and then use the user's public key to encrypt the credential key, so that the credential data stored in the service node cannot be accessed and read by others without the user's private key, ensuring the security of the user's privacy data.

[0068] To this end, after determining the registration identifier for the user, the service node can send a registration response message to the user, and the response message includes the registration information that has been generated for the user and a user public key acquisition request for the user public key, so that after receiving the response message, the user can use his own terminal or user node to generate his own public key and private key pair, and associate it with the registration identifier received from the service node, and then send the public key in the generated public key and private key pair to the service node, so that after receiving the user public key, the service node can store the user public key in association with the registration information previously generated for the user.

[0069] In addition, the name identifier in the user information in the registration request received in step S201 may also be an account name written by the user. For example, the user wishes to use a separate account name for the DID system so that other people or malicious third parties cannot easily guess the user identifier used in the DID system from the account name used on the public platform.

[0070] Therefore, in this case, the user information received in step S201 may further include words such as custom as a description of the account name, so that the service node can determine from the description in step S202 that the type of registration identifier the user wants to use is a type registered using a custom account name, and can generate a registration identifier for registration in the DID system in step S203 based on the registration identifier, i.e., the account name, included in the registration information by the user, and the identification code or information for the custom account name pre-set in the DID system.

[0071] For example, in an embodiment of the present application, the service node can use the account name included in the registration request of the user as part of the candidate registration identifier, and use the identification code of the custom registration pre-set in the system as part of the candidate registration identifier, and use the registration type of the user registration previously confirmed according to the description information as part of the candidate registration identifier, so as to generate a candidate registration identifier for registration in the DID system. Here, since the service node cannot yet determine whether there are duplicate user accounts registered therein, it cannot directly use the candidate registration identifier generated in this way as the registration information used by the user to identify himself in the DID system.

[0072] In step S203, the service node can search for the candidate registration identifier under the custom account registration type already stored on the service node according to the candidate registration identifier generated as above, for example, comparing all registered information under the custom account registration type stored in the service node with the candidate registration identifier it claims to confirm whether there is a candidate registration identifier of the custom account registration type that has been registered by others in the DID system.

[0073] When the above search result indicates that there is no registration identifier generated according to the user information in the user's registration request, the service node may use the generated candidate registration identifier as the registration identifier of the user in step S204.

[0074] After the registration identifier is generated according to the account name created by the user in step S204, the service node needs to use the user's public key to encrypt the user's credential data. For example, when receiving the user's credential data, the service node can generate a credential key for each credential data to encrypt the credential data, and then use the user's public key to encrypt the credential key, so that the credential data stored in the service node cannot be accessed and read by others without the user's private key, ensuring the security of the user's privacy data.

[0075] To this end, after step S204, the service node may further send a registration response message to the user, and include in the response message the registration information that has been generated for the user and a user public key acquisition request for the user public key, so that after receiving the response message, the user can use his own terminal or user node to generate his own public key-private key pair, and associate it with the registration identifier received from the service node, and then send the public key in the generated public key-private key pair to the service node, so that after receiving the user public key, the service node can store the user public key in association with the registration information previously generated for the user.

[0076] In addition, the name identifier in the user information in the registration request received in step S201 may also be a user public key generated by the user using his terminal or user node. In other words, the encryption of the user's credential data by the service node needs to be performed using the user's public key. For example, when receiving the user's credential data, the service node can generate a credential key for each credential data to encrypt the credential data, and then use the user's public key to encrypt the credential key, so that the credential data stored in the service node cannot be accessed and read by others without the user's private key, ensuring the security of the user's privacy data. Therefore, the user can directly use the user public key as its name identifier in the DID system, so that the user does not need to record the name identifier of the special user DID system separately, but only needs to use its own user public key as the unique identifier in the DID system to send various requests to the service node or other nodes in the DID system each time.

[0077] Therefore, in this case, the user information received in step S201 may further include a description of the account name, for example, a predetermined description term such as "user public key". Therefore, the service node can understand in step S202 based on the description information that the type of registration identification the user wants to use is a type registered using the user's user public key. Then, in step S203, the user public key can be searched under the stored user public key registration type, for example, by comparing all registered information under the user public key registration type stored in the service node with the user public key sent by the user to confirm whether there is a user public key of the user public key registration type that has been registered by others in the DID system.

[0078] When the above search result indicates that the user public key in the user's registration request does not exist, the service node may use the user public key as the registration identifier of the user in step S204.

[0079] In this case, the user's registration identifier in the DID system is the user's public key used by the service node to encrypt the user's credential key. Therefore, after the service node uses the user's public key as the user's registration identifier as above, it is no longer necessary to request the user to send the user's public key separately. Instead, the service node can only include the user's public key as registered information in the registration response information sent to the user, and can further include registration status information such as successful registration.

[0080] The diversified registration method based on the DID credential data storage area provided in the embodiment of the present application determines the registration type of the user registration based on the user information in the user's registration request sent by the user node, and searches the registered information corresponding to the registration type to see whether there is registered information matching the user information. When there is no matching registered information, the registration information of the user can be generated based on the user information. Therefore, the user can use various types of user information as their registration information in the DID system, and can avoid duplication of user registration information by querying whether there is registered information matching the user information in the registered information of the corresponding type, thereby ensuring the security of user registration while providing users with a flexible registration method.

[0081] Embodiment 3

[0082] Figure 3 This is a schematic diagram of the structure of a diversified registration device based on a DID credential data storage area provided by the present application. The diversified registration device based on a DID credential data storage area can be used to implement, for example, reference Figure 2 The embodiment of the present application provides a diversified registration method based on a DID credential data storage area. The diversified registration device based on a DID credential data storage area may include: a receiving module 31, a determining module 32, a retrieving module 33 and a generating module 34.

[0083] The receiving module 31 may be configured to receive a user registration request sent by a user node.

[0084] The receiving module 31 may be in a service node in the DID system and used to receive a registration request sent by a user through a user node. In an embodiment of the present application, a service node in the DID system may be a node for storing user information and user credential data issued by a department or unit that is legally or recognized as being able to authenticate one or more identity information of the user, and in the service node, the user's credential data is encrypted and stored, for example, using the user's own user public key, so that in the DID system, only the user who has the user's private key corresponding to the user's public key can access the credential data stored on the service node, or the user establishes authorization information for a third party, such as a user, in the service node, so that the third party can access the credential data in the service node that is authorized to be accessed by the user. Therefore, the user needs to register in the DID system so that the user's registration information can be uniquely identified by the system in the system.

[0085] The registration request received by the receiving module 31 may include user information of the user, so that, for example, the service node can create a user identifier for the user in the DID system based on the registration request, so that the user can store the credential data in the service node and manage the credential data and the credential key used to encrypt the credential data through the service node.

[0086] The determination module 32 may be configured to determine the registration type of the user according to the user information.

[0087] The determination module 32 can first determine the user's registration type according to the user information in the registration request received by the receiving module 31. In actual use, since users using the DID system are often users of other platforms or systems, they use the DID system only to present their identity information to the user through one or more credential data issued by the issuing party, thereby avoiding the disclosure of their identity information in the platform or system where the user actually uses various services. Therefore, the user of the DID system does not really want to operate or request services in the DID system. Users use the DID system to present their identity certificates in other systems or platforms. For this reason, although users need to pre-register in the DID system before they can use the system, if the user needs to record the user identification in the DID system, such as the account name or the nickname in the system, etc., due to the registration requirements of the DID system for users, it will undoubtedly greatly increase the inconvenience of the user. In this case, the user not only needs to remember the account information used on other platforms on the Internet, but also needs to remember the account information registered in the DID system according to the system requirements.

[0088] To this end, in the registration request sent by the user received by the receiving module 31, the user information may include the name identifier that the user wants to use in the DID system and the description information of the name identifier, so that the determination module 32 can understand the information related to the name identifier based on the description information, and thus process the name identifier accordingly. In other words, the diversified registration device of the embodiment of the present application has no restrictions on what user information the user uses to register. The user only needs to include the name identifier that he wants to use and the description of the name identifier in the user information in the registration request.

[0089] The search module 33 may be used to search the registered information corresponding to the registration type for the registered information that matches the user information.

[0090] The generating module 34 may be configured to generate the registration information of the user according to the user information when the search result indicates that there is no registered information matching the user information.

[0091] After the determination module 32 determines the type of account that the user wants to register based on the user information in the registration request received by the receiving module 31, the retrieval module 33 can search the registered information corresponding to the registration type stored in the service node to see whether there is registered information that matches the user information that the user wants to register, so as to ensure that the user can have a unique identification in the DID system. Therefore, when the retrieval result of the retrieval module 33 indicates that there is no registered information that matches the user information that the user wants to register, it means that the user information received by the receiving module 31 has not been registered for use by other users in the current DID system.

[0092] For example, the name identification of the user information received by the receiving module 31 can be the account name that the user has registered and used on a third-party website or platform. For example, when a user accesses a game platform or website operated by a third party to request to use the game service provided by it, the platform or website requires that the age of the user is equal to or exceeds 18 years old on the date when the user accesses the game platform or website to request to use the game service provided by it. For this reason, in the traditional prior art, the user needs to fill in the information such as his date of birth on the game platform or website operated by the third party, and upload a legally binding identity document, so that the game platform or website operated by the third party can check the user information of the user. But as mentioned above, such prior art can cause the identity information of the user to be stored on each website or platform, thereby bringing great privacy leakage risk. Users of the DID system of the embodiment of the present application can ask the gaming platform or website operated by a third party to require the user to be 18 years old or older to use the gaming service, and request the authentication party in the DID system to issue credential data for the user's age when accessing the gaming platform. The issuing party can send the credential data to the service node, so that the service node can store the credential data in its storage space and encrypt it. The user can notify the user to obtain the credential data from the service node, so that the user can confirm that the user can use the gaming service provided on its website or platform based on the credential data.

[0093] Therefore, for such users, they may want to use the account name that they have registered and used on the game platform or website they frequently visit as their name identifier in the DID system. In this way, not only do users not need to record the name representation of the special user DID system, but the third party that operates the game platform or website visited by the user can also directly request the user's credential data from the user or service node in the DID system based on the account name registered by the user on its platform.

[0094] In addition, in the case where the user uses a third-party account name, the user information received by the receiving module 31 may further include a description of the account name, for example, the name or URL of the game website to which the account name is registered. Therefore, the determination module 32 can understand from the description information that the type of registration identifier that the user wants to use is a type of registration using a third-party account, and the retrieval module 33 can send account name verification information to the website based on the URL of the website operated by a third party, for example, recorded in the description information, to request the website operated by the third party to confirm whether the account name included in the registration request sent by the user to the service node in the DID system is the account name used by the user on the website. When the website operated by the third party confirms that the account name submitted by the user to the service node in the DID system is indeed the account name registered and used on its website based on the verification information of the service node, the retrieval module 33 can generate a registration identifier for registration in the DID system based on the registration identifier, i.e., the account name, included in the registration information of the user, and the third-party information included in the description, such as the website name, or the company name of the third party, etc.

[0095] For example, in an embodiment of the present application, the retrieval module 33 may use the account name included in the registration request of the user as part of the candidate registration identifier, and use the company name or operating website name of the third party included in the description information as part of the candidate registration identifier, and use the registration type of the user registration previously confirmed based on the description information as part of the candidate registration identifier, thereby generating a candidate registration identifier for registration in the DID system.

[0096] Next, the candidate registration identifier generated as above can be used to search for the candidate registration identifier under the third-party account registration type already stored on the service node. For example, all registered information under the third-party account registration type stored in the service node can be compared with the candidate registration identifier it claims to confirm whether there is a candidate registration identifier of the third-party account registration type that has been registered by others in the DID system.

[0097] When the above search result indicates that there is no registration identifier generated according to the user information in the user's registration request, the generation module 34 may use the candidate registration identifier generated by the search module 33 as the registration identifier of the user.

[0098] In addition, after the generation module 34 generates the registration identifier according to the third-party account name specified by the user, since the service node needs to use the user's public key to encrypt the user's credential data, for example, the service node can generate a credential key for each credential data to encrypt the credential data when receiving the user's credential data, and then use the user's public key to encrypt the credential key, so that the credential data stored in the service node cannot be accessed and read by others without the user's private key, thereby ensuring the security of the user's privacy data.

[0099] To this end, after determining the registration identifier for the user, the service node can send a registration response message to the user, and the response message includes the registration information that has been generated for the user and a user public key acquisition request for the user public key, so that after receiving the response message, the user can use his own terminal or user node to generate his own public key and private key pair, and associate it with the registration identifier received from the service node, and then send the public key in the generated public key and private key pair to the service node, so that after receiving the user public key, the service node can store the user public key in association with the registration information previously generated for the user.

[0100] In addition, the name identifier in the user information in the registration request received by the receiving module 31 may also be an account name written by the user himself. For example, the user wishes to use a separate account name for the DID system so that other people or malicious third parties cannot easily guess the user identifier used in the DID system from the account name used on the public platform.

[0101] Therefore, in this case, the user information received by the receiving module 31 may further include words such as custom as a description of the account name, so that the determination module 32 can determine from the description that the type of registration identifier the user wants to use is a type of registration using a custom account name, and the retrieval module 33 can generate a registration identifier for registration in the DID system based on the registration identifier, i.e., the account name, included in the registration information by the user, and the identification code or information for the custom account name pre-set in the DID system.

[0102] For example, in an embodiment of the present application, the retrieval module 33 can use the account name included in the registration request of the user as part of the candidate registration identifier, and use the identification code of the custom registration pre-set in the system as part of the candidate registration identifier, and use the registration type of the user registration previously confirmed according to the description information as part of the candidate registration identifier, so as to generate a candidate registration identifier for registration in the DID system. Here, since the service node cannot yet determine whether there are duplicate user accounts registered therein, it is not possible to directly use the candidate registration identifier generated in this way as the registration information used by the user to identify himself in the DID system.

[0103] The retrieval module 33 can search for the candidate registration identifier under the custom account registration type already stored on the service node based on the candidate registration identifier generated as above, for example, by comparing all registered information under the custom account registration type stored in the service node with the candidate registration identifier it claims, to confirm whether there is a candidate registration identifier of the custom account registration type that has been registered by others in the DID system.

[0104] When the above search result indicates that there is no registration identifier generated according to the user information in the user's registration request, the generation module 34 may use the candidate registration identifier generated as the registration identifier of the user.

[0105] After the generation module 34 generates the registration identifier according to the account name created by the user, since the service node needs to use the user's public key to encrypt the user's credential data, for example, the service node can generate a credential key for each credential data to encrypt the credential data when receiving the user's credential data, and then use the user's public key to encrypt the credential key, so that the credential data stored in the service node cannot be accessed and read by others without the user's private key, ensuring the security of the user's privacy data.

[0106] To this end, the service node can further send a registration response message to the user, and include in the response message the registration information that has been generated for the user and a user public key acquisition request for the user public key, so that after receiving the response message, the user can use his own terminal or user node to generate his own public key and private key pair, and associate it with the registration identifier received from the service node, and then send the public key in the generated public key and private key pair to the service node, so that after receiving the user public key, the service node can store the user public key in association with the registration information previously generated for the user.

[0107] In addition, the name identifier in the user information in the registration request received by the receiving module 31 may also be a user public key generated by the user using his terminal or user node. In other words, the encryption of the user's credential data by the service node needs to be performed using the user's public key. For example, when receiving the user's credential data, the service node can generate a credential key for each credential data to encrypt the credential data, and then use the user's public key to encrypt the credential key, so that the credential data stored in the service node cannot be accessed and read by others without the user's private key, ensuring the security of the user's privacy data. Therefore, the user can directly use the user public key as its name identifier in the DID system, so that the user does not need to record the name identifier of the special user DID system in addition, but only needs to use his own user public key as the unique identifier in the DID system to send various requests to the service node or other nodes in the DID system each time.

[0108] Therefore, in this case, the user information received by the receiving module 31 may further include a description of the account name, for example, a predetermined descriptive term such as "user public key". Therefore, the determination module 32 can understand from the description information that the type of registration identification that the user wants to use is a type that is registered using the user's user public key. Then, the retrieval module 33 can search for the user public key under the stored user public key registration type, for example, by comparing all registered information under the user public key registration type stored in the service node with the user public key sent by the user to confirm whether there is a user public key of the user public key registration type that has been registered by others in the DID system.

[0109] When the above search result indicates that there is no user public key in the user's registration request, the generation module 34 can use the user public key as the registration identifier of the user.

[0110] In this case, the user's registration identifier in the DID system is the user's public key used by the service node to encrypt the user's credential key. Therefore, after the service node uses the user's public key as the user's registration identifier as above, it is no longer necessary to request the user to send the user's public key separately. Instead, the service node can only include the user's public key as registered information in the registration response information sent to the user, and can further include registration status information such as successful registration.

[0111] The diversified registration device based on the DID credential data storage area provided in the embodiment of the present application determines the registration type of the user registration based on the user information in the user's registration request sent by the user node, and searches the registered information corresponding to the registration type to see whether there is registered information matching the user information. When there is no matching registered information, the registration information of the user can be generated based on the user information. Therefore, the user can use various types of user information as their registration information in the DID system, and can avoid duplication of user registration information by querying whether there is registered information matching the user information in the registered information of the corresponding type, thereby ensuring the security of user registration while providing users with a flexible registration method.

[0112] Embodiment 4

[0113] The above describes the internal functions and structure of the diversified registration device based on the DID credential data storage area, 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 .

[0114] 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.

[0115] 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.

[0116] 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 diversified registration method based on the DID credential data storage area of ​​the above-mentioned embodiment 2.

[0117] 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 4Only some components are shown schematically, which does not mean that the electronic device only includes Figure 4 Components shown.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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 diversified registration method based on a DID credential data storage area, comprising: Receiving a user registration request sent by a user node, wherein the registration request includes user information; Determining the registration type of the user according to the user information; Retrieving registered information matching the user information from the registered information corresponding to the registration type; When the search result shows that there is no registered information matching the user information, the registration information of the user is generated according to the user information. The user information includes a registration identifier and description information, and the registration identifier is a name identifier that the user wants to use in the DID system, and the description information is information related to the registration identifier. Wherein, determining the registration type of the user according to the user information includes: When the description information indicates that the registration identifier is an account name used at a third party, determining that the registration type of the user is third-party account registration, and retrieving registered information matching the user information from the registered information corresponding to the registration type includes: Sending account name verification information to the third party according to the third party information included in the description information, wherein the account name verification information includes the registration identifier included in the user information; Receiving an account name verification response message sent by the third party; When the verification response message indicates that the third party has successfully verified the account name, generating candidate registration information according to the registration identifier and the third party information; Retrieving registered information matching the candidate registration information from the registered information corresponding to the third-party account registration type, and when the search result shows that there is no registered information matching the user information, generating the registration information of the user according to the user information includes: When the search result is that there is no registered information matching the candidate registration information, the candidate registration information is used as the registration information of the user.

2. The diversified registration method according to claim 1, wherein: Determining the registration type of the user according to the user information includes: When the description information indicates that the registration identifier is a user-defined account name, determining that the registration type is a custom registration; and retrieving the registered information matching the user information from the registered information corresponding to the registration type includes: Generate candidate registration information according to the registration identifier and the type name of the custom registration; Retrieving registered information matching the candidate registration information from the registered information corresponding to the user-defined registration type; When the search result shows that there is no registered information matching the user information, generating the registration information of the user according to the user information includes: When the search result is that there is no registered information matching the candidate registration information, the candidate registration information is used as the registration information of the user.

3. The diversified registration method according to claim 1, wherein: Determining the registration type of the user according to the user information includes: When the description information indicates that the registration identifier is a user public key of the user, determining that the registration type is user public key registration; and retrieving registered information matching the user information from the registered information corresponding to the registration type includes: Retrieving a stored user public key that matches the user public key included in the user information from among all stored user public keys; And when the search result is that there is no stored user public key matching the user public key included in the user information, generating the registration information of the user according to the user information includes: When the search result is that there is no stored user public key matching the user public key included in the user information, the user public key included in the user information is used as the registration information of the user.

4. The diversified registration method according to claim 1, wherein: The diversified registration method further comprises: Sending a registration response message to the user, wherein the registration response message includes the registration information and registration status of the user.

5. The diversified registration method according to claim 1 or 2, wherein: The diversified registration method further comprises: Sending a registration response message to the user, wherein the registration response message includes the user's registration information, registration status, and a user public key acquisition request; receiving a user public key from the user; The user public key is stored in association with the registration information.

6. A diversified registration device based on a DID credential data storage area, comprising: A receiving module, configured to receive a user registration request sent by a user node, wherein the registration request includes user information; A determination module, used to determine the registration type of the user according to the user information; A retrieval module, used to retrieve the registered information matching the user information from the registered information corresponding to the registration type; a generating module, for generating the registration information of the user according to the user information when the search result shows that there is no registered information matching the user information, The user information includes a registration identifier and description information, and the registration identifier is a name identifier that the user wants to use in the DID system, and the description information is information related to the registration identifier. Wherein, the determination module is further used for: When the description information indicates that the registration identifier is an account name used at a third party, determining that the registration type of the user is third-party account registration, and retrieving registered information matching the user information from the registered information corresponding to the registration type includes: Sending account name verification information to the third party according to the third party information included in the description information, wherein the account name verification information includes the registration identifier included in the user information; Receiving an account name verification response message sent by the third party; When the verification response message indicates that the third party has successfully verified the account name, generating candidate registration information according to the registration identifier and the third party information; Retrieving registered information matching the candidate registration information from the registered information corresponding to the third-party account registration type, and when the search result shows that there is no registered information matching the user information, generating the registration information of the user according to the user information includes: When the search result is that there is no registered information matching the candidate registration information, the candidate registration information is used as the registration information of the user.

7. An electronic device comprising: Memory, used to store programs; A processor, configured to run the program stored in the memory to execute the diversified registration method based on the DID credential data storage area as described in any one of claims 1 to 5.

8. A computer-readable storage medium having stored thereon a computer program executable by a processor, wherein: When the program is executed by a processor, a diversified registration method based on a DID credential data storage area is implemented as described in any one of claims 1 to 5.

Images