Identity credential creation method, apparatus, device, and storage medium

Abstract

The application provides an identity credential creation method and device, equipment and storage medium, and relates to the technical field of blockchains. The method comprises the following steps: in response to an identity credential creation operation for a target user, obtaining user identity information and signature information sent by the target user; based on the user identity information and the signature information, determining distributed identity identification information corresponding to the target user; creating an identity credential of the target user based on the distributed identity identification information, so that the target user performs a business operation on a decentralized application based on the identity credential. Compared with the prior art, the DID creation needs to wait for the on-chain result of the blockchain, and the user cannot perform other operations on the DAPP during the on-chain process.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a method, apparatus, device, and storage medium for creating identity credentials. Background Technology

[0002] With the development of internet technology, digital identity has gradually come into people's view. The subjects involved in digital identity are not only people, but also organizations, and even objects in the future. These people, organizations, and objects do not simply rely on the original centralized authority, cannot be taken away or deleted, and are identities carried for life.

[0003] The existing method for creating a digital identity involves the user authenticating their identity and then signing transactions with their private key, sending the transactions to the blockchain to create a Digital Identity (DID). Since the user doesn't yet have a DID, they can only apply for credentials, including identity credentials and other business credentials, after the DID is successfully created.

[0004] This DID creation method requires users to wait for the blockchain to upload the results, which is a very time-consuming process; during the upload process, users cannot perform other operations in the DApp. Summary of the Invention

[0005] The purpose of this application is to address the shortcomings of the prior art by providing a method, apparatus, device, and storage medium for creating identity credentials, thereby solving the problem that in the prior art, DID creation requires synchronous waiting for the blockchain to be uploaded, and users cannot perform other operations in the DApp during the uploading process.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0007] In a first aspect, one embodiment of this application provides a method for creating identity credentials, applied to an identity issuer system, the method comprising:

[0008] In response to the creation operation of identity credentials for the target user, the user identity information and signature information sent by the target user are obtained;

[0009] Based on the user identity information and signature information, the distributed identity identifier information corresponding to the target user is determined;

[0010] The target user's identity credentials are created based on the distributed identity information, enabling the target user to perform business operations on the decentralized application based on the identity credentials.

[0011] Secondly, another embodiment of this application provides an identity credential creation apparatus, the apparatus comprising: an acquisition module, a determination module, and a creation module, wherein:

[0012] The acquisition module is used to acquire user identity information and signature information sent by the target user in response to the identity credential creation operation for the target user.

[0013] The determining module is used to determine the distributed identity identifier information corresponding to the target user based on the user identity information and signature information;

[0014] The creation module is used to create the target user's identity credentials based on the distributed identity information, so that the target user can perform business operations on the decentralized application based on the identity credentials.

[0015] Thirdly, another embodiment of this application provides an identity credential creation device, including: a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the identity credential creation device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of any of the methods described in the first aspect above.

[0016] Fourthly, another embodiment of this application provides a storage medium storing a computer program, which, when executed by a processor, performs the steps of any of the methods described in the first aspect above.

[0017] The beneficial effects of this application are as follows: Using the identity credential creation method provided in this application, after receiving an identity credential creation operation initiated by the target user, since the creation time of identity credentials on the blockchain is relatively long, in order to ensure that the target user can obtain their DID as soon as possible for subsequent related operations, the method provided in this application, after obtaining the target user's user identity information and signature information, determines the distributed identity identifier information corresponding to the target user based on the supporter identity information and signature information, and creates the target user's identity credential based on the distributed identity identifier information. Since the target user's DID is directly calculated from the target user's supporter identity information, using the method provided in this application can reduce the waiting time for the target user to create their DID and ensure the target user's subsequent business operations on the decentralized application. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating an identity credential creation method provided in an embodiment of this application;

[0020] Figure 2 A flowchart illustrating an identity credential creation method provided in another embodiment of this application;

[0021] Figure 3 A flowchart illustrating an identity credential creation method provided in another embodiment of this application;

[0022] Figure 4 This is a schematic diagram of the structure of an identity credential creation device provided in an embodiment of this application;

[0023] Figure 5 A schematic diagram of the structure of an identity credential creation apparatus provided in another embodiment of this application;

[0024] Figure 6 This is a schematic diagram of the structure of an identity credential creation device provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of this application, but not all embodiments.

[0026] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0027] Furthermore, the flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed in order or performed simultaneously. Moreover, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0028] To ensure understanding of this application, the following explanations are provided for some of the terms used in this application:

[0029] Distributed digital identity: Distributed identity is not just for people, but also includes organizations, and even things in the future. These people, organizations, and things do not simply rely on the original centralized authority, cannot be taken away or deleted, and are identities carried for life.

[0030] Decentralized Identifiers (DIDs) are decentralized, verifiable digital identifiers characterized by their distributed nature, self-control, and cross-chain reusability. Entities can independently register, resolve, update, or revoke their DIDs. A DID is specifically resolved into a DID Document, which includes the DID's unique identifier, a list of public keys and detailed information about the public keys (holder, encryption algorithm, key status, etc.), as well as other attribute descriptions of the DID holder.

[0031] Verifiable Credentials provide a specification to describe certain attributes of an entity, enabling evidence-based trust. DID holders can use verifiable credentials to prove to other entities (individuals, organizations, things, etc.) that certain attributes of theirs are trustworthy. Furthermore, combining these credentials with cryptographic techniques such as digital signatures and zero-knowledge proofs makes the credentials even more secure and trustworthy, further protecting user privacy.

[0032] DApps (Decentralized Applications): A type of software application that runs publicly on the internet. They are no different from ordinary applications and have the same functions, but the difference is that DApps run on peer-to-peer networks.

[0033] A blockchain account has three main elements: private key, public key, and address. Among them:

[0034] Public keys and private keys are components of asymmetric encryption algorithms in cryptography. As the names suggest, public keys can be made public, while private keys must be kept securely hidden.

[0035] The private key is generated from a random seed, while the public key is derived from the private key using an algorithm. Because public keys are too long, "addresses" were introduced for simplicity and practicality; these addresses are derived from the public key. This derivation process is one-way and irreversible. That is, the address cannot be used to derive the public key, and the public key cannot be used to derive the private key.

[0036] In the VC system, the following types of participants exist:

[0037] Issuer: An entity that owns user data and can issue VCs, such as government agencies, banks, universities, and other institutions and organizations.

[0038] Holder: The holder is the user. The user requests, receives, and holds the entity of VC from the Issuer, and presents the VC to the validator. The issued VC can be stored by the user for future use, such as in a wallet.

[0039] Verifier: Accepts and verifies VCs, thereby providing some type of service to the VC presenter.

[0040] Verifiable Data Registry: A database that maintains DIDs, such as a blockchain or distributed ledger.

[0041] The overall process of DID and the VC lifecycle can include the following parts:

[0042] 1. Holder user DID registration and DID document query

[0043] 2. The issuer registers a DID and becomes an issuer.

[0044] 3. Holders apply for VC (Voucher Controller), and issuers verify the DID and issue the VC.

[0045] 4. Holder users provide VC to validators, who verify user / issuer / signature information, etc. Validators may also call the issuer to check the VC status.

[0046] The roles and information flows in the verifiable credentials ecosystem are as follows:

[0047] The issuer identifies a VC and assigns it to a holder. Issuance always occurs before any other operations involving the credential. The holder may transfer one or more VCs to others; the holder may present one or more VCs to a validator, optionally along with a VP; the validator verifies the authenticity of the presented VCs and VPs. This also includes checking the revocation status of VCs; the issuer can revoke a VC. The holder can delete a VC.

[0048] The following explanation, using several specific application examples, illustrates the method for creating identity credentials provided in this application.

[0049] In one possible implementation, embodiments of the present invention provide a method for creating identity credentials. Figure 1 This is a flowchart illustrating an identity credential creation method according to an embodiment of this application, as shown below. Figure 1 As shown, the method includes:

[0050] S101: In response to the creation operation of identity credentials for the target user, obtain the user identity information and signature information sent by the target user.

[0051] In embodiments of this application, for example, the creation of the target user's identity credentials can be determined to be triggered in response to the target user's initial opening of the decentralized application.

[0052] In some possible embodiments, the target user's identity information may be, for example, two-factor, three-factor, or four-factor identity information. Two-factor identity information may include, for example, the target user's ID card number and name; three-factor identity information may include, for example, the target user's ID card number, name, and phone number; four-factor identity information may include, for example, the ID card number, name, phone number, and facial information. It should be understood that the content of the above-described identity information is merely illustrative, and the specific amount and content of the identity information can be flexibly adjusted according to user needs, and is not limited to the embodiments described above.

[0053] In some other possible embodiments, if the target user is a corporate user, then the target user's user identity information can be the target company's corporate information. The specific content of the user identity information is set according to the type of target user and the preset information content. The above embodiments are only illustrative examples and are not limited thereto.

[0054] In one embodiment of this application, the way the identity issuer system obtains the distributed identity information corresponding to the target user can be, for example, by obtaining a message sent by the user after signing with private key information. This message includes user identity information, signature information (sign), original signature information (texWord), and public key information (publicKey). For example, it can be: rawData=sha256hash(DIDCreate+timestamp).

[0055] To protect the privacy of the target user, the message was encrypted using the target user's private key before being sent. Encryption methods could include signing the message using the target user's private key, as detailed below:

[0056]

[0057] S102: Based on user identity information, determine the distributed identity identifier information corresponding to the target user.

[0058] In some possible embodiments, the distributed identity information of the target user can be determined in the following ways:

[0059] Method 1: The DID identity issuer system uses user identity information as input parameters to calculate the target user's unique DID off-chain; for example, the target user's DID can be obtained by hashing the target user's ID card and name using the did method.

[0060] Alternatively, in method two, the target user's ID can be obtained off-chain using the blockchain's create2 method. It should be understood that the above embodiments are merely illustrative examples, and the specific method for obtaining the target user's distributed identity information can be flexibly adjusted according to the user's needs, and is not limited to the methods given in the above embodiments.

[0061] Method 1 (hash calculation method) involves performing a hash calculation using the target user's identity information to obtain the target user's ID information. The specific logic code is as follows:

[0062]

[0063] Method 2: Solidity-Create2 calculation method. The target user's ID is a contract address. The target user's ID is calculated off-chain from this contract address. The salt value used in the contract address calculation is the hash of the target user's identity information. The specific logic code is as follows:

[0064]

[0065] The method of calculating DID information off-chain not only allows the target user to obtain their corresponding DID information in advance, but also ensures that if the target user's DID information is lost, the user's identity information can be verified and hashed again to obtain the target user's DID information. In addition, this method of determining DID information can also ensure that the DID information of each real-name user is unique.

[0066] S103: Create identity credentials for the target user based on distributed identity information.

[0067] This enables target users to perform business operations on decentralized applications based on their identity credentials.

[0068] In the embodiments of this application, after the identity issuer system obtains the target user's DID, it can create an identity credential for the target user. At this time, since the DID has not yet been created, there is no need to verify whether the target user's DID has already been created on the blockchain when creating the identity credential. The identity credential is the encrypted user identity information of the target user, a credential issued by the identity issuer. When the target user performs other operations in the future, they can verify their identity by presenting the target user's identity credential. The logic code of the identity credential can be as follows:

[0069]

[0070] It should be understood that the above logic code is merely an example. The specific logic code settings and content can be adjusted according to user needs and habits, and are not limited to those given in the above embodiments.

[0071] The identity credential creation method provided in this application, upon receiving an identity credential creation operation initiated by a target user, addresses the issue that identity credential creation on the blockchain takes a considerable amount of time. Therefore, to ensure that the target user can obtain their DID as soon as possible for subsequent related operations, the method provided in this application, after obtaining the target user's user identity information and signature information, determines the target user's corresponding distributed identity identifier information based on the supporter identity information and signature information, and creates the target user's identity credential based on the distributed identity identifier information. Since the target user's DID is directly calculated from the target user's supporter identity information, the method provided in this application can reduce the waiting time for the target user to create their DID and ensure the target user's subsequent business operations on the decentralized application.

[0072] Optionally, based on the above embodiments, this application embodiment may also provide an identity credential creation method, the implementation process of which will be illustrated below with reference to the accompanying drawings. Figure 2 A flowchart illustrating an identity credential creation method according to another embodiment of this application is shown below. Figure 2 As shown, the method may further include:

[0073] S111: Obtain the target user's blockchain address information.

[0074] In embodiments of this application, the time for obtaining the blockchain address may be in response to an operation creating an identity credential for the target user, simultaneously obtaining the user's identity information, signature information, and blockchain address information sent by the target user; wherein, in order to protect the privacy of the target user, the user's identity information, signature information, and blockchain address information are concatenated to obtain a message, and then the message is encrypted using the target user's private key to ensure that the target user's privacy is not leaked during transmission.

[0075] S112: Verify user identity information.

[0076] In some possible implementations, the target user's ID card, name, mobile phone number, facial information, etc., can be verified. If one or more of the above verifications are successful, it indicates that the user currently performing the operation is the target user.

[0077] In the embodiments of this application, for example, user identity information can be verified through KYC (Know Your Customer) authentication. KYC authentication verifies the user through user information. Different institutions have different authentication methods, most of which are to authenticate ID card information, some are to authenticate passport information, and some are to authenticate green card information, etc. The authentication information is different for different applications or different countries. In short, KYC authentication is to authenticate user identity information.

[0078] S113: Verify the signature information to determine that the signature information is the signature information of the controller of the identity information corresponding to the blockchain address.

[0079] In the embodiments of this application, after obtaining the signature information, a blockchain address can be derived from the original signature text, and another blockchain address can be derived from the signature information. If the two blockchain addresses are consistent, it indicates that the current signature was issued by the target user holding the blockchain address, and the signature information verification is confirmed to be successful.

[0080] In the embodiments of this application, the target user is confirmed to have passed verification only if both the user identity information and the signature information are verified. Then, the distributed identity identifier information corresponding to the target user can be determined based on the target user's user identity information. If at least one of the user identity information and the signature information fails verification, it is determined that the current user is not the target user. In this case, a failure message for generating distributed identity identifier information is sent to the target user's terminal, so that the identity issuer system can re-obtain the user identity information and signature information sent by the target user and re-verify until verification is successful. It should be understood that the above embodiments are merely illustrative examples, and the specific feedback results and methods when verification fails can be flexibly adjusted according to user needs and are not limited to those given in the above embodiments.

[0081] In some possible embodiments, in order to protect the account security of the target user, for example, if the number of verification failures exceeds a preset threshold when the target user initiates verification, the target user cannot initiate verification again for a certain period of time.

[0082] Optionally, based on the above embodiments, this application embodiment may also provide an identity credential creation method, the implementation process of which will be illustrated below with reference to the accompanying drawings. Figure 3 A flowchart illustrating an identity credential creation method according to another embodiment of this application is shown below. Figure 3 As shown, the method may further include:

[0083] S121: Add the verified identity credential information to the identity credential creation queue.

[0084] This enables blockchain nodes to use a pre-defined identity credential contract to create each identity credential in the identity credential creation queue and execute the creation action for each identity credential.

[0085] In some possible embodiments, the identity issuer system polls the identity credential creation queue to determine whether a preset transaction threshold is met. This preset transaction threshold can be a preset transaction time threshold (e.g., a preset transaction time threshold is met at preset intervals) or a preset transaction number threshold (e.g., a preset transaction number threshold is met at N creation requests). If the threshold is met, at least one identity credential in the identity credential creation queue that meets the preset transaction threshold is placed in the pending-on-chain transaction queue. This enables the blockchain node to use the preset identity credential contract to create at least one identity credential in the target transaction body and return a creation success event upon successful creation.

[0086] In embodiments of this application, the method of placing at least one identity credential into the transaction queue to be uploaded to the blockchain can be, for example, by merging at least one identity credential that meets a preset transaction threshold in the identity credential creation queue to obtain a target transaction body; and placing the target transaction body into the transaction queue to be uploaded to the blockchain.

[0087] In other words, multiple DID creation threads continuously poll the DID creation queue, merging them into a single transaction every certain period of time or every N creation requests to obtain the transaction body and transaction hash; and then placing the transaction body (txData) into the queue of transactions to be uploaded to the blockchain; for example, merging every 10 DID creation requests or every 15 seconds into a single transaction, and signing the transaction using the issuer's blockchain account to obtain txData (transaction body) and txhash (transaction hash);

[0088] Each input parameter is related to the DID generation mode. Taking the DID generation based on hash mode as an example, the identifier and identifier content of each input parameter are as follows:

[0089]

[0090] When the DID is generated in create2 mode, the identifier and identifier content of each input parameter are as follows:

[0091]

[0092] Subsequently, multiple DID creation threads continuously query the transaction results on the blockchain through the transaction hash (txhash), i.e., the events of successful creation on the blockchain; the on-chain thread continuously polls the queue of transactions to be on-chain and sends multiple transactions to the chain in batches at once; for example, merging every 10 txData transactions into one request and sending it to the blockchain in batches; so this actually involves merging transactions twice, firstly merging 10 transactions into one on-chain transaction, and secondly sending 10 transactions to the blockchain at once.

[0093] The blockchain receives transactions and executes each transaction sequentially. The DID contract verifies the transaction initiator's permissions, polls and executes each DID creation request in turn, verifies each user's signature within the contract, determines the blockchain address of the signing user as the controller of the DID, and issues a creation success (CreateDidEvent) event. Note that the DID contract verifies that the transaction initiator must be an identity issuer; only the identity issuer can delegate DID creation. The CreateDidEvent includes the user's DID and the user's blockchain address.

[0094] When a DID is generated in hash mode, a possible approach is to create it using didIdentify as the unique identifier for the user's DID; upon successful creation, didIdentify will be uniquely associated with the user's blockchain address and blockchain public key.

[0095]

[0096] When a DID is generated in create2 mode, a possible method is as follows: use userSalt as the input parameter of create2 to create a blockchain contract on the chain and use it as the user's unique DID; calculate the user's DID contract address using userSalt, the issuer's blockchain address, and the DID contract code, which is consistent with the on-chain and off-chain calculation results. This contract address is the user's DID; after successful creation, the DID (didIdentify) will be uniquely associated with the user's blockchain address and blockchain public key.

[0097]

[0098] In the embodiments of this application, the verified identity credential information can be added to a preset database; and the flag indicating whether the identity credential was successfully created can be updated in the preset database.

[0099] In other words, multiple DID creation threads continuously query on-chain transaction results through transaction hash (txhash), i.e., events indicating successful creation on the chain. One transaction hash (txhash) can retrieve multiple creation results. Through the DID within the event, the database record is found sequentially, and the database DID is marked as successfully created on the chain.

[0100] In the embodiments of this application, if a creation success event is received from the blockchain, the target user's identity credential is marked as successfully created; creation success information is returned to the decentralized application.

[0101] In other words, after a DID is successfully created on the blockchain, the identity issuer system will asynchronously notify the DApp of the creation result; the DApp will then mark that the DID has been uploaded to the blockchain; the DApp will unlock all other functions, including credential verification; however, since credential verification requires directly calling the blockchain to query whether the user's DID has been created, the credential cannot be verified before the DID is actually uploaded to the blockchain.

[0102] In some possible implementations, if DID creation fails to complete on the blockchain for an extended period, it may be due to network or blockchain issues. An exception timer can scan the database for DID creation tasks and re-add the DID creation tasks to the DID creation queue to ensure that DID creation is ultimately successful.

[0103] The following describes the identity credential creation method provided in this application using complete embodiments:

[0104] First, the DApp collects the target user's identity information. The target user then uses their corresponding blockchain private key to sign a message, sending the user's identity information, signature information, and blockchain address information to the DID identity issuer. Subsequently, the DID identity issuer system performs KYC authentication on the user's identity information. In addition to verifying the user's identity information, the authentication also needs to verify the target user's signature information to ensure that the target user's signature is valid. The blockchain address of this signature is the controller of the DID.

[0105] After verification, the DID identity issuer system uses the user's identity information as input to calculate the target user's unique DID off-chain. For example, the ID of the target user can be obtained by hashing the ID card, name, and did method; or the target user's did can be obtained off-chain by using the blockchain's create2 method. This application does not impose any restrictions on this.

[0106] At this point, the DID identity issuer system creates identity credentials for the target user. During credential creation, it does not verify whether the target user's DID has already been created. The DID identity issuer system saves the verified DID information to the database and places the DID in the DID creation queue. The system then directly returns the DID and identity credentials to the target user, who can then obtain their own DID and identity credentials. The DID will show as being created, and the target user can perform other operations within the DApp.

[0107] Multiple DID creation threads continuously poll the DID creation queue, merging requests into a single transaction at regular intervals or every N creation requests to obtain the transaction body and transaction hash. The transaction body is then placed in the queue of transactions awaiting on-chain processing. The on-chain processing thread continuously polls the queue, sending multiple transactions in batches to the blockchain at once. Subsequently, the blockchain receives the transactions, the DID contract executes to create the DID, verifies the transaction initiator's authorization, verifies the target user's signature information within the contract, determines the signatory's blockchain address as the controller of the DID, and issues a creation success event. Multiple DID creation threads continuously query the on-chain transaction results using the transaction hash; if multiple on-chain events indicate successful creation, the DID is successfully created and batch-marked in the database. Upon successful on-chain creation, the system asynchronously notifies the DApp of the creation result. The DApp identifies the DID as being on-chain and unlocks all other functions, including credential verification.

[0108] In addition, if the creation of a DID on the blockchain fails for a long time, it may be a network or blockchain problem; the exception timer can scan the database for DID creation tasks and put the DID creation tasks back into the DID creation queue; thus ensuring that the target user's DID can eventually be successfully created.

[0109] Using the identity credential creation method provided in this application, users do not need to wait for the on-chain creation result of the DID. They only need to complete the authentication of the target user's identity information to obtain their own DID immediately and perform subsequent DApp operations. This improves system interaction efficiency and reduces the user's DID creation waiting time. Furthermore, the target user's DID is directly calculated from the target user's identity information, and each real-name user corresponds to a unique DID. The target user can retrieve the DID and identity credential that are not yet on the chain without interrupting the subsequent process of the DApp, thus improving the user's DApp usage experience. In addition, this application supports the merging of DID creation requests, batch sending of transactions, and batch querying of transaction results through asynchronous on-chain user DID creation, improving on-chain efficiency and reducing the pressure on the blockchain. Moreover, by asynchronously batching user DIDs on the chain and adding an exception mechanism, it can further ensure that the DID can be successfully created on the blockchain.

[0110] The identity credential creation apparatus provided in this application will be explained below with reference to the accompanying drawings. This identity credential creation apparatus can perform the above-described... Figures 1-3 The specific implementation and beneficial effects of any identity credential creation method are described above and will not be repeated below.

[0111] Figure 4 This is a schematic diagram of the structure of an identity credential creation device provided in an embodiment of this application, as shown below. Figure 4 As shown, the device includes: an acquisition module 201, a determination module 202, and a creation module 203, wherein:

[0112] The acquisition module 201 is used to acquire the user identity information and signature information sent by the target user in response to the identity credential creation operation for the target user.

[0113] The determination module 202 is used to determine the distributed identity identifier information corresponding to the target user based on the user's identity information and signature information;

[0114] Module 203 is used to create identity credentials for the target user based on distributed identity information, so that the target user can perform business operations on the decentralized application based on the identity credentials.

[0115] Optionally, based on the above embodiments, this application embodiment may also provide an identity credential creation device, as described below with reference to the accompanying drawings. Figure 4 The implementation process of the given device is illustrated with examples. Figure 5 This is a schematic diagram of the structure of an identity credential creation device provided in another embodiment of this application, as shown below. Figure 5 As shown, the device also includes: a verification module 204, wherein:

[0116] Module 201 is specifically used to obtain the blockchain address information of the target user.

[0117] Verification module 204 is used to verify user identity information;

[0118] The determination module 202 is specifically used to verify the signature information and determine that the signature information is the signature information of the controller of the identity information corresponding to the blockchain address.

[0119] Optionally, module 203 is specifically used to add verified identity credential information to the identity credential creation queue, so that the blockchain node uses a preset identity credential contract to execute the creation action of each identity credential based on each identity credential in the identity credential creation queue.

[0120] like Figure 5 As shown, the device also includes a sending module 205, used to send identity credentials to the target user's terminal device.

[0121] Optionally, the determining module 202 is specifically used to poll the identity credential creation queue to determine whether a preset transaction threshold is met; wherein, the preset transaction threshold is a preset transaction time threshold or a preset transaction number threshold;

[0122] If the conditions are met, module 203 is created, specifically for placing at least one identity credential that meets the preset transaction threshold in the identity credential creation queue into the transaction queue to be uploaded to the blockchain; so that the blockchain node uses the preset identity credential contract to create at least one identity credential in the target transaction body, and returns a creation success event after successful creation.

[0123] Optionally, the determining module 202 is specifically used to merge at least one identity credential that meets a preset transaction threshold in the identity credential creation queue to obtain the target transaction body;

[0124] The sending module 205 is specifically used to put the target transaction body into the queue of transactions to be uploaded to the blockchain.

[0125] like Figure 5 As shown, the device also includes: a marking module 206, used to mark the target user's identity credentials as successfully created if a creation success event is received from the blockchain;

[0126] The sending module 205 is specifically used to return a success message to the decentralized application.

[0127] Optionally, module 202 is specifically used to determine, in response to the target user's initial opening operation of the decentralized application, that the target user's identity credential creation operation has been triggered.

[0128] Optionally, the sending module 205 is specifically used to add the verified identity credential information to a preset database;

[0129] The determination module 202 is specifically used to update the flag indicating whether the identity credential has been successfully created in the preset database.

[0130] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.

[0131] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0132] Figure 6 This is a schematic diagram of the structure of an identity credential creation device provided in an embodiment of this application. The identity credential creation device can be integrated into a terminal device or a chip of a terminal device.

[0133] like Figure 6 As shown, the identity credential creation device includes: processor 501, bus 502 and storage medium 503.

[0134] Processor 501 is used to store programs, and processor 501 calls the programs stored in storage medium 503 to execute the above-mentioned programs. Figures 1-3 The corresponding method implementation is similar in both implementation and technical effect, and will not be described in detail here.

[0135] Optionally, this application also provides a program product, such as a storage medium storing a computer program, including a program that executes the embodiments corresponding to the above-described methods when run by a processor.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0137] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0138] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0139] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for creating identity credentials, characterized in that, Applied to an identity issuer system, the method includes: In response to the creation operation of identity credentials for the target user, the user identity information and signature information sent by the target user are obtained; Based on the user identity information and signature information, the distributed identity identifier information corresponding to the target user is determined; The target user's identity credential is created based on the distributed identity information. When creating the identity credential, it is not necessary to verify whether the target user's distributed identity has been verified on the blockchain. The identity credential is used to verify the target user's identity during other operations, so that the target user can perform business operations on the decentralized application based on the identity credential.

2. The method as described in claim 1, characterized in that, Before determining the distributed identity information corresponding to the target user based on the user identity information, the method further includes: Obtain the blockchain address information of the target user; Verify the user's identity information; The signature information is verified to determine that it is the signature information of the controller of the identity information corresponding to the blockchain address.

3. The method as described in claim 2, characterized in that, The method further includes: The verified identity credential information is added to the identity credential creation queue, so that the blockchain node uses a preset identity credential contract to execute the creation action of each identity credential based on each identity credential in the identity credential creation queue.

4. The method as described in claim 1, characterized in that, The method further includes: The identity credentials are sent to the target user's terminal device.

5. The method as described in claim 3, characterized in that, The method further includes: The identity credential creation queue is polled to determine whether a preset transaction threshold is met; wherein, the preset transaction threshold is a preset transaction time threshold or a preset transaction number threshold. If the conditions are met, at least one identity credential that meets the preset transaction threshold in the identity credential creation queue is placed in the transaction queue to be uploaded to the blockchain; so that the blockchain node uses the preset identity credential contract to create at least one identity credential in the target transaction body, and returns a creation success event after successful creation.

6. The method as described in claim 5, characterized in that, The step of placing at least one identity credential that meets the preset transaction threshold from the identity credential creation queue into the transaction queue to be uploaded to the blockchain includes: Merge at least one identity credential that meets the preset transaction threshold in the identity credential creation queue to obtain the target transaction body; The target transaction is placed into the queue of transactions to be uploaded to the blockchain.

7. The method as described in claim 5, characterized in that, The method further includes: If the blockchain returns a success event, then the target user's identity credentials are marked as successfully created. Return the creation success message to the decentralized application.

8. The method as described in claim 1, characterized in that, Prior to the identity credential creation operation for the target user, the method further includes: In response to the target user's initial opening of the decentralized application, it is determined that the target user's identity credential creation operation has been triggered.

9. The method as described in claim 6, characterized in that, The method further includes: The verified identity credential information is added to a preset database; If the blockchain returns a success event indicating successful creation, the method further includes: Update the flag indicating whether the identity credential was successfully created in the preset database.

10. An identity credential creation device, characterized in that, The device includes: an acquisition module, a determination module, and a creation module, wherein: The acquisition module is used to acquire user identity information and signature information sent by the target user in response to the identity credential creation operation for the target user. The determining module is used to determine the distributed identity identifier information corresponding to the target user based on the user identity information and signature information; The creation module is used to create the target user's identity credential based on the distributed identity information. When creating the identity credential, it is not necessary to verify whether the target user's distributed identity has been verified on the blockchain. The identity credential is used to verify the target user's identity during other operations, so that the target user can perform business operations on the decentralized application based on the identity credential.

11. An identity credential creation device, characterized in that, The device includes a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the identity credential creation device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the method described in any one of claims 1-9.

12. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, performs the method described in any one of claims 1-9.

Images