Decentralized Identity Processing Method, System, Computer, and Storage Medium

Abstract

The present invention provides a decentralized identity processing method, system, computer, and storage medium. The method includes: generating a parent private key, a parent public key, and a parent chain code according to a first preset method; generating a child private key, a child public key, and a child chain code based on the parent private key, the parent public key, and the parent chain code according to a second preset method; generating a parent DID and a first DID document by using the parent private key and the parent public key; generating a first wallet address; generating a child DID and a second DID document by using the child private key and the child public key; generating a second wallet address; generating a child token based on the child DID, the second DID document, and the second wallet address, and the child token has a child token ID; generating a root token based on the parent DID, the first DID document, and the first wallet address, and the child token identity field of the root token records the child token ID. By using the child token identity field of the root token to record the child token ID, the parent DID and the child DID are associated through the relationship between the root token and the child token, enabling tracing of the parent DID when the child DID is obtained, and knowing its child DID when the parent DID is obtained.

Description

Technical Field

[0001] The present invention relates to the technical field of identity information processing, and particularly relates to a decentralized identity processing method, system, computer, and storage medium. Background Art

[0002] A decentralized identifier (DID) is a new type of identifier with global uniqueness, high availability and resolvability, and cryptographic verifiability. DIDs are usually associated with cryptographic materials (such as public keys) and service endpoints to establish a secure communication channel. Its application fields include applications such as self-management and cryptographically verifiable identifiers (such as personal identifiers, organizational identifiers, and Internet of Things scenario identifiers).

[0003] In the existing DID generation schemes, the association relationship between the parent DID and the child DID is that the child DID is generated by the parent DID, but there is no association relationship between the parent DID and the child DID itself, resulting in that in actual applications, it is impossible to trace the origin between the child DID and the parent DID. Summary of the Invention

[0004] Based on this, it is necessary to provide a decentralized identity processing method, system, computer, and storage medium for the above technical problems.

[0005] A decentralized identity processing method includes:

[0006] Generating a parent private key, a parent public key, and a parent chain code according to a first preset method;

[0007] Based on the parent private key, the parent public key, and the parent chain code, generating a child private key, a child public key, and a child chain code according to a second preset method;

[0008] Generating a parent DID and a first DID document by using the parent private key and the parent public key;

[0009] Generating a first wallet address;

[0010] Generating a child DID and a second DID document by using the child private key and the child public key;

[0011] Generating a second wallet address;

[0012] Generating a child token based on the child DID, the second DID document, and the second wallet address, where the child token has a child token ID;

[0013] Generating a root token based on the parent DID, the first DID document, and the first wallet address, where the child token identity field of the root token records the child token ID.

[0014] In one embodiment, the step of generating a root token based on the parent DID, the first DID document, and the first wallet address includes:

[0015] Put the parent DID into the first token name, point the first document URL to the first DID document, use the first wallet address as the first token owner, and generate the root token based on the first token name, the first document URL, and the first token owner. Wherein, the sub-token identity field of the root token records the sub-token ID.

[0016] In one embodiment, the step of generating a root token based on the parent DID, the first DID document, and the first wallet address includes:

[0017] Put the parent DID into the first token name, point the first document URL to the first DID document, use the first wallet address as the first token owner, sign the token minting transaction with the first wallet private key, and generate the root token based on the first token name, the first document URL, and the first token owner. Wherein, the sub-token identity field of the root token records the sub-token ID.

[0018] In one embodiment, the step of generating a sub-token based on the sub-DID, the second DID document, and the second wallet address includes:

[0019] Put the sub-DID into the second token name, point the second document URL to the second DID document, use the root token as the second token owner, and generate the sub-token based on the second token name, the second document URL, and the second token owner.

[0020] In one embodiment, the step of generating a sub-token based on the sub-DID, the second DID document, and the second wallet address includes:

[0021] Put the sub-DID into the second token name, point the second document URL to the second DID document, use the root token as the second token owner, sign the token minting transaction with the second wallet private key, and generate the sub-token based on the second token name, the second document URL, and the second token owner.

[0022] In one embodiment, the step of generating a parent DID and a first DID document using the parent private key and the parent public key includes:

[0023] Obtain a first DID registration request;

[0024] Sign the first DID registration request using the parent private key, generate the first DID document based on the first DID registration request, and save the parent public key in the first DID document.

[0025] In one embodiment, the step of generating a child DID and a second DID document using the child private key and the child public key includes:

[0026] Obtain a second DID registration request;

[0027] Sign the second DID registration request using the child private key, generate the second DID document based on the second DID registration request, and save the child public key in the second DID document.

[0028] A decentralized identity processing device includes:

[0029] A parent secret key generation module for generating a parent private key, a parent public key, and a parent chain code according to a first preset method;

[0030] A child secret key generation module for generating a child private key, a child public key, and a child chain code according to a second preset method based on the parent private key, the parent public key, and the parent chain code;

[0031] A parent DID generation module for generating a parent DID and a first DID document using the parent private key and the parent public key;

[0032] A first wallet generation module for generating a first wallet address;

[0033] A child DID generation module for generating a child DID and a second DID document using the child private key and the child public key;

[0034] A second wallet generation module for generating a second wallet address;

[0035] A child token generation module for generating a child token based on the child DID, the second DID document, and the second wallet address, where the child token has a child token ID;

[0036] A parent token generation module for generating a root token based on the parent DID, the first DID document, and the first wallet address, where the child token identity field of the root token records the child token ID.

[0037] A computer device includes a memory and a processor, the memory stores a computer program, and is characterized in that when the processor executes the computer program, the following steps are implemented:

[0038] Generate a parent private key, a parent public key, and a parent chain code according to a first preset method;

[0039] Generate a child private key, a child public key, and a child chain code according to a second preset method based on the parent private key, the parent public key, and the parent chain code;

[0040] Generate a parent DID and a first DID document by using the parent private key and the parent public key;

[0041] Generate a first wallet address;

[0042] Generate a child DID and a second DID document by using the child private key and the child public key;

[0043] Generate a second wallet address;

[0044] Generate a child token based on the child DID, the second DID document, and the second wallet address, where the child token has a child token ID;

[0045] Generate a root token based on the parent DID, the first DID document, and the first wallet address, where the child token identity field of the root token records the child token ID.

[0046] A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0047] Generate a parent private key, a parent public key, and a parent chain code according to a first preset method;

[0048] Generate a child private key, a child public key, and a child chain code according to a second preset method based on the parent private key, the parent public key, and the parent chain code;

[0049] Generate a parent DID and a first DID document by using the parent private key and the parent public key;

[0050] Generate a first wallet address;

[0051] Generate a child DID and a second DID document by using the child private key and the child public key;

[0052] Generate a second wallet address;

[0053] Generate a child token based on the child DID, the second DID document, and the second wallet address, where the child token has a child token ID;

[0054] Generate a root token based on the parent DID, the first DID document, and the first wallet address, where the child token identity field of the root token records the child token ID.

[0055] The above decentralized identity processing method, system, computer, and storage medium use non-fungible tokens to store decentralized identities, and record the sub-token ID in the sub-token identity field of the root token, enabling the parent DID and the sub-DID to be associated through the relationship between the root token and the sub-token. It can trace the parent DID when obtaining the sub-DID, or know its sub-DID when obtaining the parent DID, thus realizing the traceability between the sub-DID and the parent DID. Description of the Drawings

[0056] Figure 1 It is a schematic flowchart of the decentralized identity processing method in an embodiment;

[0057] Figure 2 It is a block diagram of the modules of the decentralized identity processing device in an embodiment;

[0058] Figure 3 It is an internal structure diagram of a computer device in an embodiment;

[0059] Figure 4 It is a schematic flowchart of generating a parent private key, a parent public key, and a parent chain code according to a first preset method in an embodiment;

[0060] Figure 5 It is a schematic flowchart of generating a sub-private key, a sub-public key, and a sub-chain code according to a second preset method in an embodiment;

[0061] Figure 6 It is a schematic flowchart of generating a wallet address in an embodiment;

[0062] Figure 7 It is a block diagram of the data structure of an NFT in an embodiment;

[0063] Figure 8 It is a schematic flowchart of the registration process of a DID in an embodiment. Detailed Embodiments

[0064] In order to make the objectives, technical solutions, and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0065] Embodiment 1

[0066] In this embodiment, as Figure 1 shown, a decentralized identity processing method is provided, including:

[0067] Step 110, generate a parent private key, a parent public key, and a parent chain code according to a first preset method.

[0068] In this embodiment, as Figure 4As shown in the figure, the first preset method is as follows: First, generate mnemonics (Mnemonics401), generate a parent seed (parent seed 402) according to the mnemonics, perform a one-way encrypted hash calculation on the parent seed. The one-way encrypted hash algorithm can adopt the SHA512 algorithm to generate an N-bit hash value (N-bit Hash403). The left M bits (Left M bits 404) of the N-bit hash value generate a parent private key (parent Private Key406), and the right N-M bits (RightN-M bits 405) of the N-bit hash value generate a parent chain code (parent Chain Code 408). The parent chain code can prevent subsequent child password calculations from completely depending on the password itself and increase entropy for the child password. The parent public key (parentPublic Key 407) is generated by performing a one-way encrypted hash calculation on the parent private key.

[0069] Step 120: Based on the parent private key, the parent public key, and the parent chain code, generate a child private key, a child public key, and a child chain code according to a second preset method.

[0070] In this embodiment, as Figure 5 shown in the figure, perform a one-way encrypted hash calculation on the combination of the parent private key (parent Private Key 501), the parent chain code (parentChain Code 502), and the index value (Index Number(A)503) to generate an N-bit hash value (N-bit Hash 504). Among them, for each additional child DID, the index value is incremented by 1 in sequence. The left M bits (Left M bits 505) of the N-bit hash value generate a child private key (index A) (Child(Index A)Private Key 507), and the right N-M bits (Right N-M bits 506) of the N-bit hash value generate a child chain code (index A) (Child(Index A)Chain Code 509). The child public key (index A) (Child Public Key(lndexA)508) is generated by performing a one-way encrypted hash calculation on the child private key (index A).

[0071] In this embodiment, although the child private key, the child public key, and the child chain code are calculated from the parent private key, the parent public key, and the parent chain code, the generated child private key, child public key, and child chain code have no association relationship with the parent private key, the parent public key, and the parent chain code at this time. It is impossible to trace back to the parent private key, the parent public key, and the parent chain code only relying on the child private key, the child public key, and the child chain code.

[0072] Step 130: Generate a parent DID and a first DID document by using the parent private key and the parent public key.

[0073] In this embodiment, the DID registration API (Application Programming Interface) is called to generate a parent DID and a first DID document (First DID Document).

[0074] Step 140: Generate a first wallet address.

[0075] In this embodiment, as Figure 6 shown, the first wallet address is generated according to the following process. First, a private key is generated using a random number generator (RANDOM). The private key is processed by the SECP256K1 algorithm to generate a public key. The public key is successively encrypted using the SHA256 encryption algorithm and the RIPEMD160 encryption algorithm to obtain a public key hash. The public key hash is encrypted using the DOUBLE SHA256 encryption algorithm to obtain an encrypted hash value. The first 4 bytes of the encrypted hash value are used as a check value and combined with the public key hash. The combined public key hash and check value are encoded using BASE58 to obtain the wallet address.

[0076] Step 150: Generate a child DID and a second DID document using the child private key and the child public key.

[0077] In this embodiment, the DID registration API is called to generate a child DID and a second DID document (Second DID Document).

[0078] Step 160: Generate a second wallet address.

[0079] In this embodiment, the second wallet address is generated using the process as Figure 6 shown.

[0080] Step 170: Generate a child token based on the child DID, the second DID document, and the second wallet address. The child token has a child token ID.

[0081] Step 180: Generate a root token based on the parent DID, the first DID document, and the first wallet address. The child token identity field of the root token records the child token ID.

[0082] In this embodiment, both the child token and the root token are non-fungible tokens (Non-Fungible Tokens). Non-fungible tokens are the tokenization of digital or real-world assets and have the characteristics of being irreplaceable and indivisible. NFTs are issued on the blockchain and are used to specify ownership in areas such as artworks, game props, domain names, identity authentication, copyrights, leases, etc. Each NFT is associated with some unique data, usually some kind of digital content file (or a reference to it), and is managed by a smart contract.

[0083] Specifically, for the data structure of NFT, please refer to Figure 7 . NFT includes a Token ID field, a Token Name field, a Token Owner field, a Child Token ID field, and a Document URL field. The functions of each field are as follows:

[0084] Token ID, the unique identification of the NFT on the blockchain, used to identify the NFT and distinguish different NFTs.

[0085] Token Name, the token name, a human-readable description of the NFT, which is a globally unique identifier for the DID. It does not require a central registration agency and is registered and managed through distributed ledger technology (DLT) or other forms of decentralized networks. The format is as follows: did:example:1234567890abcdefghi. The DID is divided into three parts. The first part is the DID Scheme (similar to protocols such as http, https, ftp in URLs); the second part is the DID method identifier, usually the name of the DID method; the third part is the specific identifier in the DID method, which is unique in the entire DID method namespace.

[0086] Token Owner, used to represent the owner of a token. For the root token in this embodiment, its owner is the wallet address where it is located, and the owner of its child tokens is the root token, and so on.

[0087] Child Token ID, used to represent the IDs of all child tokens under a token. Its data format can be an array or a linked list.

[0088] Document URL, pointing to the location of the DID Document associated with the DID identified by this token. The DID Document contains all information related to the DID subject. In the Doc, there are identity information verification methods, including encryption public keys, related addresses, etc.

[0089] In this embodiment, child tokens and root tokens are generated using child DIDs and parent DIDs respectively, and the Child Token ID field of the root token records the child token ID of the child token, so that the parent DID is associated with the child DID.

[0090] In the above embodiments, non-fungible tokens are used to store decentralized identities. The child token identity field of the root token is used to record the child token ID, so that the parent DID and the child DID are associated through the relationship between the root token and the child token. It is possible to trace the parent DID when the child DID is obtained, or to know its child DID when the parent DID is obtained, thus realizing the traceability between the child DID and the parent DID.

[0091] In one embodiment, the step of generating a root token based on the parent DID, the first DID document, and the first wallet address includes: putting the parent DID into the first token name, pointing the first document URL to the first DID document, using the first wallet address as the owner of the first token, and generating the root token based on the first token name, the first document URL, and the owner of the first token. The child token identity field of the root token records the child token ID.

[0092] In this embodiment, putting the parent DID into the first token name means putting the parent DID into the Token Name field of the root token, pointing the first Document URL field to the first DID Document, the value of the Token owner field of the root token is the first wallet address, and the ChildTokenID of the root token records the Token ID of the child token, so that the root token and the child token are associated, and the child token can be found through the ChildTokenID of the root token.

[0093] In one embodiment, the step of generating a root token based on the parent DID, the first DID document, and the first wallet address includes: putting the parent DID into the first token name, pointing the first document URL to the first DID document, using the first wallet address as the owner of the first token, signing the token minting transaction with the private key of the first wallet, and generating the root token based on the first token name, the first document URL, and the owner of the first token. The child token identity field of the root token records the child token ID.

[0094] In this embodiment, a first wallet is generated at the same time as the first wallet address, and the private key of the first wallet is generated. After obtaining the values of the first token name, the first document URL, and the owner of the first token, the private key of the first wallet is used to sign the token minting transaction of the root token, thereby generating the root token.

[0095] In one embodiment, the step of generating a sub-token based on the sub-DID, the second DID document, and the second wallet address includes: placing the sub-DID in a second token name, pointing a second document URL to the second DID document, using the root token as the owner of the second token, and generating the sub-token based on the second token name, the second document URL, and the owner of the second token.

[0096] In this embodiment, placing the sub-DID in the second token name means placing the sub-DID in the Token Name field of the sub-token, and pointing the second Document URL field to the second DID Document. The value of the Token owner field of the sub-token is the Token ID of the root token. In this way, the sub-token can be associated with the root token, and the root token can be found through the Token owner field of the sub-token.

[0097] In one embodiment, the step of generating a sub-token based on the sub-DID, the second DID document, and the second wallet address includes: placing the sub-DID in a second token name, pointing a second document URL to the second DID document, using the root token as the owner of the second token, signing the token minting transaction with the private key of the second wallet, and generating the sub-token based on the second token name, the second document URL, and the owner of the second token.

[0098] In this embodiment, a second wallet is generated at the same time as the second wallet address is generated, and the private key of the second wallet is generated. After obtaining the values of the second token name, the second document URL, and the owner of the second token, the private key of the second wallet is used to sign the token minting transaction of the sub-token, thereby generating the sub-token.

[0099] In one embodiment, the step of generating a parent DID and a first DID document using the parent private key and the parent public key includes: obtaining a first DID registration request; signing the first DID registration request with the parent private key, generating the first DID document based on the first DID registration request, and saving the parent public key in the first DID document.

[0100] In this embodiment, after the parent private key and the parent public key are generated, the first DID registration request is signed with the parent private key, and the parent public key is saved in the first DID document.

[0101] In one embodiment, the step of generating the sub-DID and the second DID document by using the sub-private key and the sub-public key includes: obtaining a second DID registration request; signing the second DID registration request by using the sub-private key, generating the second DID document based on the second DID registration request, and saving the sub-public key in the second DID document.

[0102] In this embodiment, after generating the sub-private key and the sub-public key, the first DID registration request is signed by using the sub-private key, and the sub-public key is saved in the second DID document.

[0103] It should be understood that although Figure 1 the steps in the flowchart are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise clearly stated in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. For example, step 180 can be executed before step 170, or can be executed simultaneously with step 170. Moreover, Figure 1 at least a part of the steps in

[0104] Embodiment 2

[0105] In this embodiment, as Figure 4 shown, a mnemonic is generated, a seed (parent seed) is generated according to the mnemonic, a one-way encrypted hash calculation (such as the SHA512 algorithm) is performed on the seed to generate an N-bit hash value, the left M bits of the N-bit hash value generate the parent private key, and the right N-M bits generate the parent chain code, avoiding the subsequent sub-password calculation being completely dependent on the password itself, increasing the entropy for the sub-password, and generating the parent public key by performing a one-way encrypted hash calculation on the parent private key.

[0106] As Figure 5 shown, a one-way encrypted hash calculation is performed on the combination of the parent private key, the parent chain code, and the index value (the index value is incremented by 1 for each additional sub-DID) to generate an N-bit hash value. The left M bits of the N-bit hash value generate the sub-private key (index A), and the right N-M bits generate the sub-chain code (index A). The sub-public key (index A) is generated by performing a one-way encrypted hash calculation on the sub-private key (index A). It should be understood that the association relationship between the parent DID and the sub-DID obtained by implementing the current steps is that the sub-DID is generated by the parent DID, but there is no association relationship between the parent-sub DID itself, which is not easy to trace.

[0107] In this embodiment, a composable non-fungible token (CNFT) is used to store decentralized identities, and the parent-child relationship between DIDs is reflected based on the organizational structure of the CNFT. As Figure 7 shown, it is the data structure of the CNFT metadata, including but not limited to:

[0108] Token ID, which uniquely identifies the NFT on the blockchain.

[0109] Token Name, a human-readable description of the NFT. In the present invention, it is the globally unique identifier of the DID, which does not require a central registration authority and is registered and managed through distributed ledger technology (DLT) or other forms of decentralized networks. The format is as follows:

[0110] did:example:1234567890abcdefghi. The DID is divided into three parts. As shown above, the first part is the DID Scheme (similar to protocols such as http, https, ftp in URLs); the second part is the DID method identifier (generally the name of the DID method); the third part is the specific identifier in the DID method: it is unique in the entire DID method namespace.

[0111] Token Owner, which is used to represent the owner of a token. For the root token (i.e., the first generated token) in the present invention, its owner is the public address of its wallet, and the owner of its child tokens is the root token, and so on.

[0112] ChildTokenID, which is used to represent the IDs of all child tokens under a token, and its data format can be an array or a linked list.

[0113] Document URL, which points to the location of the DID Document associated with the DID identified by this token. The DID Document (DID Doc) contains all information related to the DID subject, and there are identity information verification methods (including encryption public keys, related addresses, etc.) in the Doc.

[0114] As Figure 6As shown in the figure, generate a wallet: First, use a random number generator to generate a private key. The private key is processed by the SECP256K1 algorithm to generate a public key. After processing the public key, the wallet address is obtained. Specifically, first use a random number generator (RANDOM) to generate a private key. The private key is processed by the SECP256K1 algorithm to generate a public key. The public key is successively encrypted by the SHA256 encryption algorithm and the RIPEMD160 encryption algorithm to obtain the public key hash. The public key hash is encrypted by the DOUBLE SHA256 encryption algorithm to obtain the encrypted hash value. The first 4 bytes of the encrypted hash value are used as the check value and combined with the public key hash. The combined public key hash and check value are encoded in BASE58 to obtain the wallet address.

[0115] Generate the root token: Generate the parent private key, parent public key, and parent chain code. After generating the parent key pair, sign the DID registration request with the parent private key. The public key is saved in the parent DID Document. Call the DID registration API. After success, obtain the parent DID and parent DID Document. Put the obtained DID into the Token Name of the parent token. The Document URL points to the parent DID Document. The Token owner of the parent token is the wallet address. Use the wallet private key to sign the parent token minting transaction to generate the root token.

[0116] Generate the child token: Generate the child private key, child public key, and child chain code. After generating the child key pair, sign the DID registration request with the child private key. The child public key is saved in the child DID Document. Call the DID registration API. After success, obtain the child DID and child DID Document. Put the obtained DID into the child token Token Name. The Document URL points to the child DID Document. The Token owner of the child token is the Token ID of its parent token. Use the wallet private key to sign the child token minting transaction to generate the child token. Record the child token Token ID in the ChildTokenID of its parent token.

[0117] In this embodiment, the user agent in the DID system is an application used to generate DIDs, manage data and permissions, and sign / verify DID-related statements. This application can be the same application as the wallet in the above figure or a different application. Therefore, the command service can be deployed in the DID system user agent application, or in the wallet, or in an independent application.

[0118] As Figure 8As shown, the request receiver is used to receive user service requests, such as registering a parent DID or a child DID. The request processor analyzes the service request to determine whether the task should be sent to the user agent or first sent to the wallet to obtain the DID hierarchy. The task relay obtains the service request processing result and sends the request to the user agent or the wallet. If it is first sent to the wallet, after obtaining the DID hierarchy information from the wallet, the task relay also needs to send the corresponding service request and hierarchy information to the user agent. Data synchronization provides the corresponding information to the wallet after a certain DID is generated or deleted in the user agent, completing the change of the wallet token hierarchy.

[0119] Embodiment 3

[0120] In this embodiment, as Figure 2 shown, a decentralized identity processing device is provided, including:

[0121] A parent key generation module 210, configured to generate a parent private key, a parent public key, and a parent chain code according to a first preset method;

[0122] A child key generation module 220, configured to generate a child private key, a child public key, and a child chain code based on the parent private key, the parent public key, and the parent chain code according to a second preset method;

[0123] A parent DID generation module 230, configured to generate a parent DID and a first DID document by using the parent private key and the parent public key;

[0124] A first wallet generation module 240, configured to generate a first wallet address;

[0125] A child DID generation module 250, configured to generate a child DID and a second DID document by using the child private key and the child public key;

[0126] A second wallet generation module 260, configured to generate a second wallet address;

[0127] A child token generation module 270, configured to generate a child token based on the child DID, the second DID document, and the second wallet address, where the child token has a child token ID;

[0128] A parent token generation module 280, configured to generate a root token based on the parent DID, the first DID document, and the first wallet address, where the child token identity field of the root token records the child token ID.

[0129] In one embodiment, the parent token generation module is further configured to place the parent DID into a first token name, point a first document URL to the first DID document, use the first wallet address as the first token owner, and generate the root token based on the first token name, the first document URL, and the first token owner, wherein the sub-token identity field of the root token records the sub-token ID.

[0130] In one embodiment, the parent token generation module is further configured to place the parent DID into a first token name, point a first document URL to the first DID document, use the first wallet address as the first token owner, sign the token minting transaction with the first wallet private key, and generate the root token based on the first token name, the first document URL, and the first token owner, wherein the sub-token identity field of the root token records the sub-token ID.

[0131] In one embodiment, the sub-token generation module is further configured to place the sub-DID into a second token name, point a second document URL to the second DID document, use the root token as the second token owner, and generate the sub-token based on the second token name, the second document URL, and the second token owner.

[0132] In one embodiment, the sub-token generation module is further configured to place the sub-DID into a second token name, point a second document URL to the second DID document, use the root token as the second token owner, sign the token minting transaction with the second wallet private key, and generate the sub-token based on the second token name, the second document URL, and the second token owner.

[0133] In one embodiment, the parent DID generation module includes:

[0134] A first registration request acquisition unit, configured to acquire a first DID registration request;

[0135] A parent DID generation unit, configured to sign the first DID registration request with the parent private key, generate the first DID document based on the first DID registration request, and save the parent public key in the first DID document.

[0136] In one embodiment, the steps of the sub-DID generation module generating the sub-DID and the second DID document by using the sub-private key and the sub-public key include:

[0137] A second registration request acquisition unit, configured to acquire a second DID registration request;

[0138] The sub-DID generation unit is used to sign the second DID registration request by using the sub-private key, generate the second DID document based on the second DID registration request, and save the sub-public key in the second DID document.

[0139] For the specific limitations of the decentralized identity processing device, reference can be made to the limitations on the decentralized identity processing method in the following text, which will not be elaborated here. Each component or each independent part in the above-mentioned decentralized identity processing system can be implemented in whole or in part by software, hardware, and their combination. The above-mentioned each component or each independent part can be embedded in the processor of the computer device in hardware form or be independent of it, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above-mentioned each unit.

[0140] Embodiment 4

[0141] In this embodiment, a computer device is provided. Its internal structure diagram can be as Figure 3 shown. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program, and a database is deployed on the non-volatile storage medium, and the database is used to store user behavior data and user portraits. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with other computer devices on which application software is deployed. When the computer program is executed by the processor, it implements a decentralized identity processing method. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covered on the display screen, or a button, a trackball, or a touchpad provided on the housing of the computer device, or an external keyboard, a touchpad, or a mouse, etc.

[0142] Those skilled in the art can understand that Figure 3 the structure shown in

[0143] is only a block diagram of a part of the structure related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0144] Generate a parent private key, a parent public key, and a parent chain code according to a first preset method;

[0145] Based on the parent private key, the parent public key, and the parent chain code, generate a child private key, a child public key, and a child chain code according to a second preset method;

[0146] Generate a parent DID and a first DID document by using the parent private key and the parent public key;

[0147] Generate a first wallet address;

[0148] Generate a child DID and a second DID document by using the child private key and the child public key;

[0149] Generate a second wallet address;

[0150] Generate a child token based on the child DID, the second DID document, and the second wallet address, where the child token has a child token ID;

[0151] Generate a root token based on the parent DID, the first DID document, and the first wallet address, where the child token identity field of the root token records the child token ID.

[0152] In one embodiment, when the processor executes the computer program, the following steps are further implemented:

[0153] Put the parent DID into a first token name, point a first document URL to the first DID document, use the first wallet address as the first token owner, and generate the root token based on the first token name, the first document URL, and the first token owner, where the child token identity field of the root token records the child token ID.

[0154] In one embodiment, when the processor executes the computer program, the following steps are further implemented:

[0155] Put the parent DID into a first token name, point a first document URL to the first DID document, use the first wallet address as the first token owner, sign the token minting transaction with the first wallet private key, and generate the root token based on the first token name, the first document URL, and the first token owner, where the child token identity field of the root token records the child token ID.

[0156] In one embodiment, when the processor executes the computer program, the following steps are further implemented:

[0157] Put the child DID into a second token name, point a second document URL to the second DID document, use the root token as the second token owner, and generate the child token based on the second token name, the second document URL, and the second token owner.

[0158] In one embodiment, when the processor executes the computer program, the following steps are further implemented:

[0159] Put the sub-DID into the second token name, point the second document URL to the second DID document, use the root token as the owner of the second token, sign the token minting transaction with the second wallet private key, and generate the sub-token based on the second token name, the second document URL, and the second token owner.

[0160] In one embodiment, when the processor executes the computer program, the following steps are further implemented:

[0161] Obtain a first DID registration request;

[0162] Sign the first DID registration request with the parent private key, generate the first DID document based on the first DID registration request, and save the parent public key in the first DID document.

[0163] In one embodiment, when the processor executes the computer program, the following steps are further implemented:

[0164] Obtain a second DID registration request;

[0165] Sign the second DID registration request with the sub-private key, generate the second DID document based on the second DID registration request, and save the sub-public key in the second DID document.

[0166] Embodiment Five

[0167] In this embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0168] Generate a parent private key, a parent public key, and a parent chain code according to a first preset method;

[0169] Based on the parent private key, the parent public key, and the parent chain code, generate a sub-private key, a sub-public key, and a sub-chain code according to a second preset method;

[0170] Generate a parent DID and a first DID document by using the parent private key and the parent public key;

[0171] Generate a first wallet address;

[0172] Generate a sub-DID and a second DID document by using the sub-private key and the sub-public key;

[0173] Generate a second wallet address;

[0174] Generate a sub-token based on the sub-DID, the second DID document, and the second wallet address, where the sub-token has a sub-token ID;

[0175] Generate a root token based on the parent DID, the first DID document, and the first wallet address, where the sub-token identity field of the root token records the sub-token ID.

[0176] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0177] Put the parent DID into the first token name, point the first document URL to the first DID document, use the first wallet address as the first token owner, and generate the root token based on the first token name, the first document URL, and the first token owner, where the sub-token identity field of the root token records the sub-token ID.

[0178] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0179] Put the parent DID into the first token name, point the first document URL to the first DID document, use the first wallet address as the first token owner, sign the token minting transaction with the first wallet private key, and generate the root token based on the first token name, the first document URL, and the first token owner, where the sub-token identity field of the root token records the sub-token ID.

[0180] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0181] Put the sub-DID into the second token name, point the second document URL to the second DID document, use the root token as the second token owner, and generate the sub-token based on the second token name, the second document URL, and the second token owner.

[0182] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0183] Put the sub-DID into the second token name, point the second document URL to the second DID document, use the root token as the second token owner, sign the token minting transaction with the second wallet private key, and generate the sub-token based on the second token name, the second document URL, and the second token owner.

[0184] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0185] Obtain a first DID registration request;

[0186] Sign the first DID registration request using the parent private key, generate the first DID document based on the first DID registration request, and save the parent public key in the first DID document.

[0187] In one embodiment, when the computer program is executed by a processor, the following steps are further implemented:

[0188] Obtain a second DID registration request;

[0189] Sign the second DID registration request using the child private key, generate the second DID document based on the second DID registration request, and save the child public key in the second DID document.

[0190] Those of ordinary skill in the art can understand that all or part of the processes of implementing the methods in the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database, or other medium used in the various embodiments provided in this application can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

[0191] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this specification.

[0192] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all fall within the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the appended claims.

Claims

1. A decentralized identity processing method, characterized in that, Including: Generating a parent private key, a parent public key, and a parent chain code according to a first preset method; Generating a child private key, a child public key, and a child chain code according to a second preset method based on the parent private key, the parent public key, and the parent chain code; Generating a parent DID and a first DID document by using the parent private key and the parent public key; Generating a first wallet address; Generating a child DID and a second DID document by using the child private key and the child public key; Generating a second wallet address; Generating a child token based on the child DID, the second DID document, and the second wallet address, where the child token has a child token ID; Generating a root token based on the parent DID, the first DID document, and the first wallet address, where the child token identity field of the root token records the child token ID.

2. The method according to claim 1, characterized in that, The step of generating the root token based on the parent DID, the first DID document, and the first wallet address includes: Putting the parent DID into a first token name, pointing a first document URL to the first DID document, using the first wallet address as the first token owner, and generating the root token based on the first token name, the first document URL, and the first token owner, where the child token identity field of the root token records the child token ID.

3. The method according to claim 2, characterized in that, The step of generating the root token based on the parent DID, the first DID document, and the first wallet address includes: Putting the parent DID into a first token name, pointing a first document URL to the first DID document, using the first wallet address as the first token owner, signing a token minting transaction with a first wallet private key, and generating the root token based on the first token name, the first document URL, and the first token owner, where the child token identity field of the root token records the child token ID.

4. The method according to claim 1, characterized in that, The step of generating the child token based on the child DID, the second DID document, and the second wallet address includes: Putting the child DID into a second token name, pointing a second document URL to the second DID document, using the root token as the second token owner, and generating the child token based on the second token name, the second document URL, and the second token owner.

5. The method according to claim 4, characterized in that, The step of generating the child token based on the child DID, the second DID document, and the second wallet address includes: Putting the child DID into a second token name, pointing a second document URL to the second DID document, using the root token as the second token owner, signing a token minting transaction with a second wallet private key, and generating the child token based on the second token name, the second document URL, and the second token owner.

6. The method according to claim 1, characterized in that, The step of generating the parent DID and the first DID document by using the parent private key and the parent public key includes: Obtaining a first DID registration request; Signing the first DID registration request with the parent private key, generating the first DID document based on the first DID registration request, and saving the parent public key in the first DID document.

7. The method according to claim 1, characterized in that, The step of generating the child DID and the second DID document by using the child private key and the child public key includes: Obtain a second DID registration request; Sign the second DID registration request using the sub-private key, generate the second DID document based on the second DID registration request, and save the sub-public key in the second DID document.

8. A decentralized identity processing device, characterized in that, Including: A parent key generation module for generating a parent private key, a parent public key, and a parent chain code according to a first preset method; A sub-key generation module for generating a sub-private key, a sub-public key, and a sub-chain code based on the parent private key, the parent public key, and the parent chain code according to a second preset method; A parent DID generation module for generating a parent DID and a first DID document using the parent private key and the parent public key; A first wallet generation module for generating a first wallet address; A sub-DID generation module for generating a sub-DID and a second DID document using the sub-private key and the sub-public key; A second wallet generation module for generating a second wallet address; A sub-token generation module for generating a sub-token based on the sub-DID, the second DID document, and the second wallet address, where the sub-token has a sub-token ID; A parent token generation module for generating a root token based on the parent DID, the first DID document, and the first wallet address, where the sub-token identity field of the root token records the sub-token ID.

9. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images