CN114846765B

CN114846765B - Method and apparatus for providing decentralised identity verification

Info

Publication number: CN114846765B
Application number: CN202080085675.4A
Authority: CN
Inventors: 袁园; 曹圣皎; 杨仁慧; 方晖; 刘佳伟; 杨伟涛
Original assignee: Alipay Labs Singapore Pte Ltd
Current assignee: Alipay Labs Singapore Pte Ltd
Priority date: 2020-01-09
Filing date: 2020-12-31
Publication date: 2024-01-09
Anticipated expiration: 2040-12-31
Also published as: CN114846765A; WO2021139605A1; SG10202000215RA

Abstract

Methods, apparatus, and devices, including computer programs stored on computer-readable media, for providing decentralised identity verification are disclosed herein. The method comprises the following steps: recording an encrypted de-centralized identification (DID) received from the first user; recording a request for confirming the authenticity of the encrypted DID, the request being received from a second user; receiving a reply to the confirmation request and a proof for proving that the third user is entitled to reply to the confirmation request from a third user; recording a reply to the confirmation request; and in response to determining that the proof is acceptable, indicating that the reply is valid.

Description

Method and apparatus for providing decentralised identity verification

Technical Field

This document relates generally to computer technology and, more particularly, to methods and apparatus for providing decentralized authentication.

Background

Traditional authentication may use physical documents such as government issued identity cards, passports, etc. to identify users. However, these files are not intended to be shared electronically, and sharing the information contained in such files may expose the user to potential hazards, such as identity theft, etc.

A Decentralised Identity (DID) is an identity that a user can create and manage by himself. DID may reduce the need for a centralized organization in identity management, and DID may allow users to retain control over their own identity. Current implementations of DID include using DID in a decentralized network. Such a de-centralized network may include a blockchain system.

Blockchain systems, also known as Distributed Ledger Systems (DLS) or consensus systems, may enable participating entities to store data securely and non-tamperably. The blockchain system may include any DLS and may be used with public blockchain networks, private blockchain networks, and federated blockchain networks without reference to any particular use case. The public blockchain network opens the usage system to all entities and participates in the consensus process. The private blockchain network is provided for a specific entity that centrally controls read and write rights. The federated blockchain network is provided for selected entity groups that control the consensus process, and includes an access control layer.

Users of the blockchain system may include, for example, individuals, businesses, banks, financial institutions, hospitals, and other types of companies, organizations, and the like. Some of the users may create DID and attempt to use their DID to prove their identity to others. For example, a first user, referred to as a DID owner, may create a DID containing some identifiable information. The identifiable information may include, for example, name, address, telephone number, email address, and other types of information that the DID owner would like to use as part of the DID. Once the DID is created, the DID owner may attempt to obtain some type of validation from a second user (referred to as an Issuer (Issuer)) that would like to have a validation file digitally signed by the Issuer (e.g., using the Issuer's private key) to validate the identity of the DID owner. The issuer may be willing to have such a validation file because the issuer has some type of relationship with the DID owner. For example, the DID owner may use an e-commerce platform provided by the issuer, in which case the issuer may be willing to issue a confirmation file confirming the identity of the DID owner upon request by the DID owner. In another example, the DID owner may be an employee of the issuer, in which case the issuer may be willing to have a confirmation file that confirms employment of the DID owner.

After the issuer issues a validation file confirming the identity of the DID owner, the DID owner may encrypt the validation file, e.g., using a cryptographic hash value, and record a copy of the encrypted validation file on the blockchain system. The DID owner may then provide an unencrypted validation file to a third User, referred to as a trusted User (trusted User), in an attempt to prove the identity of the DID owner to the trusted User. The trusted user may be, for example, a service provider or a bank that wants to verify the identity of the DID owner before providing a service or issuing a loan to the DID owner. After verification, the trusted user may acknowledge that the identity claimed by the DID owner is true.

While the use of such DID may allow users to retain control over their own identity, doing so may require the DID owners to have the ability to store and manage the validation files they received from the various issuers. For example, if the DID owner requested multiple validation files from multiple issuers, the DID owner may need to be responsible for storing and managing the multiple validation files. Managing multiple validation files can become complex and time consuming.

Disclosure of Invention

In one aspect, a computer-implemented method for providing decentralized authentication includes: recording an encrypted de-centralized identification (DID) received from the first user; recording a request for confirming the authenticity of the encrypted DID, the request being received from a second user; receiving a reply to the confirmation request and a proof for proving that the third user is entitled to reply to the confirmation request from a third user; recording a reply to the confirmation request; and in response to determining that the proof is acceptable, indicating that the reply is valid.

In another aspect, an apparatus for providing decentralised identity verification comprises: one or more processors; one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to: recording an encrypted de-centralized identification (DID) received from the first user; recording a request for confirming the authenticity of the encrypted DID, the request being received from a second user; receiving a reply to the confirmation request and a proof for proving that the third user is entitled to reply to the confirmation request from a third user; recording a reply to the confirmation request; and in response to determining that the proof is acceptable, indicating that the reply is valid.

In another aspect, a non-transitory computer readable medium has instructions stored therein that, when executed by a processor of a device, cause the device to perform a method for providing de-centralized authentication. The method comprises the following steps: recording an encrypted de-centralized identification (DID) received from the first user; recording a request for confirming the authenticity of the encrypted DID, the request being received from a second user; receiving a reply to the confirmation request and a proof for proving that the third user is entitled to reply to the confirmation request from a third user; recording a reply to the confirmation request; and in response to determining that the proof is acceptable, indicating that the reply is valid.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description with reference to the drawings, the same reference numerals in different drawings denote the same or similar elements unless otherwise specified.

FIG. 1 is a schematic diagram of a blockchain system in accordance with embodiments.

FIG. 2 is a schematic diagram of a computing device for implementing nodes in a blockchain system in accordance with embodiments.

Fig. 3 is a flow chart of a method for providing decentralised identity verification according to an embodiment.

Fig. 4 is a flow diagram of a method for providing decentralised identity verification according to an embodiment.

Fig. 5 is a block diagram of an apparatus for providing decentralised identity verification according to an embodiment.

Detailed Description

Embodiments herein provide methods and apparatus for providing decentralised identity verification. The method and apparatus may allow a first user of the blockchain system (referred to as a DID owner) to define its own de-centralized identification (DID) and record an encrypted (e.g., hashed) version of the DID on the blockchain system. The method and apparatus may also allow a DID owner to present a DID to a second User of the blockchain system (referred to as a trusted User) who may verify the validity of the DID presented by the DID owner based on the encrypted DID recorded in the blockchain system. The method and apparatus may also allow a trusted user to record a request on the blockchain system for confirming the authenticity of an encrypted DID recorded on the blockchain system. The method and apparatus may allow a third user of the blockchain system, referred to as a replier, to reply to the request for the record with a proof that the replier is eligible to reply to the request for the record. In this way, the method and apparatus can support DID verification without the Issuer (Issuer) having any validation files, which in turn eliminates the need for the DID owner to store and manage validation files.

The embodiments disclosed herein have one or more technical effects. In some embodiments, the methods and apparatus support recording encrypted DID on a blockchain system. This allows the method and apparatus to facilitate centralized authentication using a blockchain system and allows trusted users to verify the validity of a DID based on an encrypted DID recorded on the blockchain system. In some embodiments, the methods and apparatus support recording requests on a blockchain system. This allows the method and apparatus to provide a mechanism for trusted users to request confirmation of the authenticity of encrypted DID recorded on the blockchain system. In some embodiments, the methods and apparatus also support recording replies to requests recorded on the blockchain system. This allows the method and apparatus to provide a mechanism for the replier to reply to the request for the record. In some embodiments, the methods and apparatus also support protocols that require the replier to provide evidence with each reply. This allows the method and apparatus to provide trust for the trusted user. In this way, the trusted user can trust that the replier is entitled to reply to the record request, thereby eliminating the need to confirm the file.

The blockchain system is implemented using a peer-to-peer (P2P) network, where nodes communicate directly with each other, e.g., without the need for a fixed central server. Each node in the P2P network may initiate communication with another node in the P2P network. The blockchain system maintains one or more blockchains.

Blockchains are data structures that can store data, such as transactions, in a manner that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this manner may be immutable and subsequently verified. A blockchain includes one or more blocks. Each block is connected to the immediately preceding block by a cryptographic hash value (cryptographic hash) comprising the immediately preceding block. Each chunk may also include a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have typically been verified by nodes of a blockchain system may be hashed and encoded into a data structure such as a merck (Merkle) tree. In a Merkle tree, the data at the leaf nodes is hashed, and all hash values in each branch of the tree may be concatenated at the root of the branch. This process continues along the tree until the root of the entire tree, where hash values representing all the data in the tree are stored. Hash values of transactions purported to be stored in a tree can be quickly verified by determining if they are consistent with the structure of the tree.

The blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. The network may be a public blockchain network, a private blockchain network, or a federated blockchain network. For example, many entities, such as hundreds, thousands, or even millions of entities may operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network with respect to participating entities. Sometimes, most entities (nodes) must sign each block to make the block valid and be added to the blockchain of the blockchain network. An exemplary public blockchain network includes a particular point-to-point payment network that utilizes a distributed ledger called a blockchain.

In general, public blockchain networks may support public transactions. The public transaction is shared by all nodes within the public blockchain network and stored in the global blockchain. The global blockchain is a blockchain that replicates across all nodes, and all nodes are in a fully-consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add blocks to the blockchain), a consensus protocol is implemented in the public blockchain network. Examples of consensus protocols include proof-of-work (POW) (e.g., implemented in some cryptocurrency networks), proof-of-rights (POS), and proof-of-authority (POA).

In general, a private blockchain network may be provided for a particular entity that centrally controls read and write rights. The entity controls which nodes can participate in the blockchain network. Thus, private blockchain networks are often referred to as licensed networks, which limit who is allowed to participate in the network, as well as their participation level (e.g., only in certain transactions). Various types of access control mechanisms may be used (e.g., existing participants vote to add new entities, and a regulatory agency may control admission).

Typically, federated blockchain networks are proprietary between the participating entities. In a federated blockchain network, the consensus process is controlled by a set of authorized nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation consisting of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, each entity may operate at least one node in the federated blockchain network. Thus, a federated blockchain network may be considered a private network that is associated with a participating entity. In some examples, each entity (node) must sign each chunk in order for the chunk to be valid and added to the blockchain. In some examples, at least a subset of entities (nodes) (e.g., at least 7 entities) must sign each block in order for the block to be valid and added to the blockchain.

FIG. 1 illustrates a schematic diagram of a blockchain system 100 in accordance with embodiments. Referring to FIG. 1, a blockchain system 100 may include a plurality of nodes, such as nodes 102-110, configured to operate on a blockchain 120. Nodes 102-110 may form a network 112, such as a point-to-point (P2P) network. Each of the nodes 102-110 may be a computing device, such as a computer or computer system, configured to store a copy of the blockchain 120, or may be software, such as a process or application, running on the computing device. Each of the nodes 102-110 may have a unique identification.

The blockchain 120 may include an incremental list of records in the form of blocks of data, such as blocks B1-B5 in fig. 1. Each of the blocks B1-B5 may include a timestamp, a cryptographic hash value of a previous block, and data of a current block, which may be a transaction such as a monetary transaction. For example, as shown in fig. 1, block B5 may include a timestamp, the encrypted hash of block B4, and the transaction data of block B5. Further, for example, a hash operation may be performed on a previous chunk to generate an encrypted hash of the previous chunk. The hash operation may convert various lengths of input to a fixed length of encrypted output by a hash algorithm such as SHA-256.

Nodes 102-110 may be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data onto the blockchain 120, the node may generate a new chunk to be added to the blockchain 120 and broadcast the new chunk to other nodes in the network 112, such as nodes 104-110. Based on the validity of the new chunk, e.g., its signature and the validity of the transaction, other nodes may determine to accept the new chunk so that node 102 and other nodes may add the new chunk to their respective copies of blockchain 120. As this process repeats, more and more blocks of data may be added to the blockchain 120.

FIG. 2 illustrates a schematic diagram of a computing device 200 for implementing a node (e.g., node 102 (FIG. 1)) in a blockchain system in accordance with embodiments. Referring to fig. 2, a computing device 200 may include a communication interface 202, a processor 204, and a memory 206.

Communication interface 202 may facilitate communication between computing device 200 and devices used to implement other nodes in a network, such as nodes 104-110 (fig. 1). In some embodiments, communication interface 202 may be used to support one or more communication standards, such as the Internet standard or protocol, the Integrated Services Digital Network (ISDN) standard, and so forth. In some embodiments, the communication interface 202 may include one or more of the following: local Area Network (LAN) cards, cable modems, satellite modems, data buses, cables, wireless communication channels, radio-based communication channels, cellular communication channels, internet Protocol (IP) -based communication devices, or other communication devices for wired and/or wireless communication. In some embodiments, the communication interface 202 may be based on public cloud infrastructure, private cloud infrastructure, hybrid public/private cloud infrastructure.

The processor 204 may include one or more special purpose processing units, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), or various other types of processors or processing units. The processor 204 is coupled to the memory 206 and is configured to execute instructions stored in the memory 206.

Memory 206 may store processor-executable instructions and data such as a copy of blockchain 120 (fig. 1). The memory 206 may include any type or combination of volatile or nonvolatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, or magnetic or optical disk. The computing device 200 may perform operations on the blockchain 120 when the instructions in the memory 206 are executed by the processor 204.

Fig. 3 shows a flow diagram of a method 300 for providing decentralised identity verification according to an embodiment. As shown in fig. 3, multiple users may have accounts on a blockchain, such as blockchain 120 (fig. 1). Blockchains may be implemented to support various types of users or parties, including, for example, individuals, businesses, banks, financial institutions, hospitals, and other types of companies, organizations, and the like.

For purposes of illustration, three users are depicted in FIG. 3, including a DID owner, a trusted user, and a replier. The DID owner may create a Decentralised Identity (DID) and attempt to prove its identity using the DID. The trusted user may receive the DID from the DID owner, verify the validity of the DID, record a validation request on the blockchain, and rely on the blockchain to validate the authenticity of the DID. The replying person may notice the request recorded on the blockchain and provide a reply and proof on the blockchain to help the trusted user confirm the authenticity of the DID. In some embodiments, the DID owner, trusted user, and replier may operate according to the method 300.

In step 302, the DID owner may generate a DID. In some embodiments, the DID owner may generate the DID based on various types of information. For example, if the DID owner is a merchant selling a product on an e-commerce platform, the DID owner may choose to generate the DID based on the DID owner name and one or more orders received by the DID owner through the e-commerce platform. In another example, if the DID owner holds a bank account, the DID owner may choose to generate the DID based on the DID owner name and an account number associated with the bank account. It should be appreciated that the DID owners may generate different DID based on different types of information. However, for the purpose of illustration, the following example may describe a DID owner that chooses to generate a DID based on order related information received by the DID owner through an e-commerce platform. The DID generated in this way may contain data fields including, for example { name: "ABC", order number: "001", year of order: "2019", order month: "September" }.

In some embodiments, at step 302, the DID owner may encrypt the DID, for example, using a hash function or encryption algorithm. Continuing with the example above, the encrypted DID may contain a data field that includes, for example, { name: "hsiffeuwfh 398", order number: "eghuefredu09f9", order year: "57835fegre4oifnj", order month: "8n349t349tnalen" }, where "hsiffeuwfh 398", "eghuefreduce 09f9", "57835fegre4oifnj" and "8n349t349tnalen" may represent encrypted values of "ABC", "001", "2019" and "september", respectively.

At step 304, the DID owner may submit the encrypted DID to the blockchain for recording.

At step 306, the blockchain may record the encrypted DID submitted by the DID owner. In some embodiments, the blockchain may provide the DID owner with a record number that may be used to retrieve the encrypted DID. In some embodiments, the record number may include an address indicating the location of the encrypted DID record on the blockchain. However, it should be understood that the record number may be generated in various other ways.

In step 308, the DID owner may provide the DID to the trusted user, such as { name: "ABC", order number: "001", year of order: "2019", order month: "September" }. The DID owner may provide the DID to the trusted user for various reasons, including, for example, proving the identity of the DID owner to the trusted user. The trusted user may be, for example, a service provider or a bank that wants to verify the identity of the DID owner before providing a service or issuing a loan to the DID owner.

In step 310, the trusted user may encrypt the DID received from the DID owner using the same encryption mechanism used by the DID owner in step 302. The trusted user may then verify the validity of the encrypted DID recorded on the blockchain by determining whether the encryption result calculated by the trusted user at step 310 matches the DID. In some embodiments, if the record number is provided by the DID owner, the trusted user may use the record number to retrieve the encrypted DID recorded on the blockchain and compare the encrypted DID retrieved from the blockchain to the encryption result calculated by the trusted user at step 310. In some embodiments, the trusted user may search for a record on the blockchain that matches the encryption result calculated by the trusted user at step 310. In some embodiments, if the encryption result calculated by the trusted user at step 310 does not match any encrypted DID recorded on the blockchain, the trusted user may refuse to accept the identity of the DID owner. On the other hand, if the trusted user determines that the encryption result calculated at step 310 matches the encrypted DID recorded on the blockchain, the trusted user may proceed to step 312.

At step 312, the trusted user may submit a confirmation request to the blockchain. In some embodiments, a trusted user may request confirmation of the authenticity of an encrypted DID recorded on a blockchain. In some embodiments, a trusted user may submit a request with a record number that may be used to retrieve encrypted DIDs recorded on the blockchain. In some embodiments, the trusted user may submit the request using an encrypted DID as its payload, which may include, for example { name: "hsiffeuwfh 398", order number: "eghuefredu09f9", order year: "57835fegre4oifnj", order month: "8n349t349tnalen" }.

At step 314, the blockchain may record the acknowledgement request. In some embodiments, once the validation request is recorded on the blockchain, the request may become visible to other users of the blockchain, including, for example, users having data access rights to the e-commerce platform on which the DID owner received the order (i.e., the DID owner was used to generate the DID order in step 302). In some embodiments, the blockchain may broadcast the confirmation request on the blockchain, and a user receiving the broadcast may retrieve the encrypted DID from the blockchain and determine whether the encrypted DID contains a data field that they can verify. If a user determines that the encrypted DID contains a data field that the user can verify (e.g., the user has data access rights to the e-commerce platform described in the above example), the user may agree to act as a replier to the validation request and proceed to step 316.

At step 316, the replier may retrieve the encrypted DID from the blockchain that needs to be validated. If the trusted user submits a confirmation request with a record number, the replier may use the record number to retrieve the encrypted DID. If a trusted user submits an encrypted DID as a confirmation request for its payload, the replier may retrieve the encrypted DID from the payload.

At step 318, the replier may determine the authenticity of the encrypted DID and generate a reply based on the determined authenticity. In some embodiments, the replier may determine the authenticity of the encrypted DID by verifying the encrypted value associated with the data field contained in the encrypted DID. Continuing with the example above, the encrypted DID contains, for example, { name: "hsiffeuwfh 398", order number: "eghuefredu09f9", order year: "57835fegre4oifnj", order month: "8n349t349tnalen" }, the replier can determine the authenticity of this encrypted DID by verifying the encrypted values associated with name, order number, order year and order month. Because the replier has data access rights to the e-commerce platform from which the DID owner received the order, the replier may retrieve plaintext values for the name ("ABC"), order number ("001"), order year ("2019"), order month ("september") from one or more data storage devices used by the e-commerce platform. The replier may then calculate the encrypted value for the name, order number, order year, and order month, respectively, and compare the calculated encrypted value to the encrypted value associated with the data field contained in the encrypted DID. The replier may determine that the authenticity of a particular data field is true if the calculated encryption value for that particular data field matches the encryption value associated with the corresponding data field contained in the encrypted DID. If the calculated encryption value for a particular data field does not match the encryption value associated with the corresponding data field contained in the encrypted DID, the replier may determine that the authenticity of the particular data field is "false".

In some embodiments, the replier may determine the authenticity of the data fields contained in the encrypted DID and generate a reply that individually indicates the authenticity determined for each data field. Such replies may include, for example { name: "true/false", order number: "true/false", order year: "true/false", order month: "true/false" }. In some embodiments, the replier may determine the authenticity of the data fields contained in the encrypted DID and indicate the authenticity of the encrypted DID as a whole. In this way, if the replier determines that one of the data fields contained in the encrypted DID is "false", the replier may indicate the authenticity of the encrypted DID as a whole as "false". It should be appreciated that the replier may indicate the determined authenticity in various other ways. For example, in some embodiments, if the replier does not have a plaintext value for a particular data field contained in the encrypted DID, the replier may indicate that the particular data field is "unverified". It should be appreciated that other types of indications may be used by the replier.

The replier may also generate a proof indicating that the replier is eligible to determine the authenticity of the encrypted DID at step 318. In some embodiments, the replier may generate the proof as a zero knowledge proof. Zero knowledge proof refers to a technique that allows a prover to prove to a verifier that a claim is true without revealing any information beyond the validity of the claim itself. At step 318, the replier is a prover that may prove to the blockchain or an intelligent contract executing on the blockchain (as a verifier) that the replier is eligible to determine the authenticity of the encrypted DID. The replier may attempt to prove this by indicating that: (1) The replier has access to the plaintext values of the data fields contained in the encrypted DID, and (2) the replier is indeed the replier itself.

In some embodiments, the replier and blockchain may agree to implement Zero-knowledge proof techniques, such as Zero-knowledge compact non-interactive knowledge proof (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, zk-snare), and the like. The replier may prove to the blockchain that: the replier knows the secret input w so that some relationship between x and w holds for the common input x. In some embodiments, the relationship may be defined as an arithmetic circuit (arithmetic circuit). In some embodiments, the arithmetic circuit may be defined based on a polynomial equation, which may be evaluated based on x and w. In some embodiments, the attestation key and the validation key may be generated during a setup phase based on the arithmetic circuitry and one or more security parameters established for zero knowledge attestation. Those of ordinary skill in the art will appreciate that the setup phase may be performed by a trusted party or by multiple independent parties using multi-party computing collaboration.

In some embodiments, the replier may set w to a value generated based on the plaintext values of the data fields contained in the encrypted DID (to prove that the replier may access the plaintext values of these data fields) and the replier's private key (to prove that the replier is indeed the replier itself). For example, w may be generated by concatenating the plaintext value of the data field contained in the encrypted DID with the replier's private key. In this way, the replier may use the secret input and the public input and the attestation key to generate attestation to attest to the blockchain that the replier owns the secret input w. In some embodiments, the blockchain may verify the attestation using a common input and a verification key generated during the setup phase. In some embodiments, if the blockchain accepts proof of the replier, i.e., the replier has secret input w, the blockchain may accept the declaration of the replier as true.

At step 320, the replier may submit the reply and proof to the blockchain for recording. In some embodiments, the blockchain may record replies and certificates submitted by the replier.

At step 322, the blockchain may examine the proof to determine if the replier has secret input w. In some embodiments, the blockchain may examine the proof in response to a validation request submitted by the replier, which in some embodiments may submit the validation request as a separate transaction from the submission of the reply and proof performed at step 320. In some embodiments, the blockchain may provide the determination using one or more intelligent contracts executing on the blockchain. The smart contract may be a computer protocol implemented in computer code that is incorporated into the blockchain to facilitate, verify, or conduct negotiations or execution of the contract. For example, a user of the blockchain may program agreed-upon terms into a smart contract using a programming language such as c++, java, solidity, python, etc., and when the terms are met, the smart contract may be automatically executed by the blockchain, such as executing a transaction. For another example, an intelligent contract may include a plurality of subroutines or functions, each of which may be a series of program instructions that perform a dedicated task. The smart contract may be an operation code that is executed without human interaction in whole or in part.

In some embodiments, the smart contract may be incorporated into the blockchain to determine whether the proof is acceptable. The smart contract may verify the proof using a public input and a verification key. If the proof cannot be verified, the smart contract may refuse to accept the reply submitted by the replier as valid. On the other hand, if the proof can be verified, the smart contract can determine that the proof is acceptable and accept replies submitted by the replier as valid. In some embodiments, the smart contract may record an indication (e.g., a flag, bit, data field, etc.) indicating the validity of the reply. In some embodiments, replies and their validity may become visible to other users of the blockchain, including, for example, trusted users. The trusted user may then proceed to step 324.

At step 324, the trusted user may retrieve the reply from the blockchain and process the reply to determine whether to accept or reject the DID provided by the DID owner. In some embodiments, a trusted user may process the reply only if the reply is deemed valid by the smart contract. In some embodiments, the trusted user may determine whether to accept or reject the DID provided by the DID owner based on the authenticity indicated in the reply. For example, if the reply indicates that all data fields contained in the encrypted DID are "true," the trusted user may conclude that all data fields contained in the DID provided by the DID owner are "true" and accept the DID provided by the DID owner. On the other hand, if the reply indicates that one or more data fields contained in the encrypted DID are "false", the trusted user may conclude that one or more data fields contained in the DID provided by the DID owner are "false" and refuse to accept the DID provided by the DID owner. In some embodiments, a trusted user may establish a tolerance threshold (tolerance threshold) that allows a certain number of data fields to be considered "false" or "unverified" and still be willing to accept the DID provided by the DID owner. It should be appreciated that whether and how such tolerance thresholds are implemented may vary from one trusted user to another.

At step 326, the trusted user may inform the DID owner of whether the DID provided by the DID owner was accepted or rejected.

It should be appreciated that while the above example describes a DID owner selecting to generate a DID based on order related information that it received through the e-commerce platform, such an implementation is provided as an example only and is not meant to be limiting. The DID owner may generate the DID based on various types of information that the DID owner would like to use as its identity. Furthermore, it should be understood that the foregoing description of functions, variables, and transactions are presented by way of example only and are not meant to be limiting.

It should also be appreciated that the method 300 allows the DID owner to prove its identity to the trusted user by sending its DID in plain text to the trusted user. In this way, the method 300 may support DID verification without requiring the replier to issue any validation files, which in turn eliminates the need for the DID owner to store and manage any validation files.

Fig. 4 shows a flow diagram of a method 400 for providing decentralised identity verification according to an embodiment. The method 400 may be performed by one or more nodes in a blockchain system, such as the nodes 102-110 in the blockchain system 100 (fig. 1). Nodes 102-110 in blockchain system 100 may perform operations on a blockchain, such as blockchain 120 (fig. 1). The blockchain 120 may be implemented as the blockchain in the examples described above.

At step 402, a node, such as node 102, may record an encrypted DID received from a first user. The first user may be, for example, a DID owner (fig. 3). The encrypted DID may include a plurality of encrypted values corresponding to a plurality of data fields. For example, the encrypted DID described in the example above may include { name: "hsiffeuwfh 398", order number: "eghuefredu09f9", order year: "57835fegre4oifnj", order month: "8n349t349tnalen" }.

At step 404, the node 102 may record a request for confirming the authenticity of the encrypted DID. The request may be received from a second user. The second user may be, for example, a trusted user (fig. 3). The trusted user may be, for example, a service provider or a bank that wants to verify the identity of the DID owner before providing a service or issuing a loan to the DID owner. Once the request is recorded, the request may become visible to other users of the blockchain 120, including, for example, a third user. The third user may be, for example, a replier (fig. 3).

At step 406, the node 102 may receive a reply to the request from a third user and a proof for proving that the third user is eligible to reply to the request. In some embodiments, the reply may include an indication of authenticity of each of the plurality of data fields included in the encrypted DID. For example, if the encrypted DID includes { name: "hsiffeuwfh 398", order number: "eghuefredu09f9", order year: "57835fegre4oifnj", order month: "8n349t349tnalen" }, the reply may include an indication of the authenticity of each of the plurality of data fields (i.e., name, order number, order year, and order month). In some embodiments, the authenticity indicator may have a value of "true" or "false" indicating whether the encrypted value corresponding to each particular data field is true. In some embodiments, the authenticity indication may also indicate whether a particular data field is "unverified". Further, in some embodiments, the reply may include an indication of authenticity of the encrypted DID as a whole. In some embodiments, if the replier determines that one of the data fields contained in the encrypted DID is "false," the replier may indicate that the authenticity of the encrypted DID as a whole is "false.

At step 408, node 102 may record the reply. Node 102 may also determine whether the proof is acceptable. In some embodiments, the proof may include a zero knowledge proof. In some embodiments, the third user may use the attestation to attest to the node 102 that the third user possesses the secret input described above. In some embodiments, if the node 102 determines that the proof is not acceptable, the node 102 may report an error and/or record an indication that the reply is invalid. On the other hand, if the node 102 determines that the proof is acceptable, the node 102 may record an indication that the reply is valid. The reply and its indication of validity may become visible to other users of blockchain 120, including, for example, trusted users. If the reply is valid, the trusted user may then retrieve and process the reply as described above.

Fig. 5 is a block diagram of an off-center avatar authentication device 500 according to an embodiment. Apparatus 500 may be an implementation of a software process and may correspond to method 400 (fig. 4). Referring to fig. 5, an apparatus 500 may include a receiving module 502, a recording module 504, a determining module 506, and a reporting module 508.

The receiving module 502 may receive an encrypted DID from a first user. The receiving module 502 may also receive a request from the second user for confirmation of the authenticity of the encrypted DID. The receiving module 502 may provide the encrypted DID and the request to the recording module 504, and the recording module 504 may record the encrypted DID and the request in a data storage device, such as a blockchain system.

The receiving module 502 may also receive a reply to the request and a proof from the third user that the third user is eligible to reply to the request. The receiving module 502 may provide the reply to the recording module 504, and the recording module 504 may record the reply. The receiving module 502 may provide the proof to the determining module 506, and the determining module 506 may determine whether the proof is acceptable. If the proof is not acceptable, the determination module 506 may request the reporting module 508 to report an error and/or record an indication that the reply is invalid. Otherwise, the determination module 506 may request the recording module 504 to record an indication that the reply is valid. If the reply is valid, the reply and its validity indication may become visible to the second user, who may then retrieve and process the reply as described above.

Each of the above modules may be implemented as software or hardware, or a combination of software and hardware. For example, each of the modules described above may be implemented using a processor executing instructions stored in memory. Also, for example, each of the above-described modules may be implemented using one or more Application Specific Integrated Circuits (ASICs), digital Signal Processors (DSPs), digital Signal Processing Devices (DSPDs), programmable Logic Devices (PLDs), field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for performing the described methods. Further, for example, each of the above modules may be implemented by using a computer chip or entity, or by using a product having a specific function. In one embodiment, the apparatus 500 may be a computer, and the computer may be a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet, a wearable device, or any combination of these devices.

For the implementation of the functions and roles of each module in the apparatus 500, reference may be made to the corresponding steps in the method described above. Details are omitted here for brevity.

In some embodiments, a computer program product may include a non-transitory computer readable storage medium having computer readable program instructions stored thereon for causing a processor to perform the above-described method.

A computer readable storage medium may be a tangible device that can store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium would include the following: portable computer diskette, hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static Random Access Memory (SRAM), portable compact disc read-only memory (CD-ROM), digital Versatile Disc (DVD), memory stick, floppy disk, mechanical coding device such as a punch card or protrusion structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.

The computer readable program instructions for performing the methods described above may be assembly instructions, instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object-oriented programming language and conventional procedural programming languages. The computer readable program instructions may execute entirely on the computing device as a stand alone software package, or partly on a first computing device and partly on a second computing device remote from the first computing device. In the latter scenario, the second remote computing device may be connected to the first computing device through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN).

The computer readable program instructions may be provided to a processor of a general purpose or special purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the methods described above.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments herein. In this regard, blocks in the flowchart or block diagrams may represent software programs, segments, or portions of code, which comprise one or more executable instructions for implementing the specified functions. It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the diagrams and/or flowchart illustration, and combinations of blocks in the diagrams and flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It is appreciated that certain features of the specification, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features that are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or in any other described embodiment herein. Unless otherwise indicated, certain features described in the context of various embodiments are not essential features of those embodiments.

Although the present disclosure has been described in conjunction with specific embodiments, many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the following claims are intended to embrace all such alternatives, modifications and variances which fall within the scope of the appended claims.

Claims

1. A computer-implemented method for providing decentralised identity verification for application to one or more nodes in a blockchain system, the method comprising:

recording an encrypted de-centering identification DID received from a first user;

recording a request for confirming the authenticity of the encrypted DID, the request being received from a second user;

Receiving a reply to the confirmation request from a third user and a proof proving that the third user is entitled to reply to the confirmation request;

recording a reply to the confirmation request; and

in response to determining that the proof is acceptable, the reply is indicated as valid.

2. The method of claim 1, further comprising:

in response to determining that the proof is unacceptable, an error is reported.

3. A method as claimed in any preceding claim, wherein the proof is a zero knowledge proof.

4. The method of claim 1, further comprising:

the reply is provided to the second user.

5. The method of claim 1, wherein the encrypted DID comprises a plurality of encrypted values corresponding to a plurality of data fields.

6. The method of claim 5, wherein the reply to the confirmation request includes an indication of authenticity for each of the plurality of data fields.

7. The method of claim 6, wherein the authenticity indicator for each particular data field of the plurality of data fields indicates whether the encrypted value corresponding to the particular data field is true.

8. An apparatus for providing off-center avatar authentication, comprising:

One or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the method of any of claims 1-7.

9. An apparatus for providing off-center avatar authentication, the apparatus comprising:

and a receiving module: receiving an encrypted de-centralized identification DID from a first user; receiving a request from a second user for confirmation of the authenticity of the encrypted DID; receiving a reply to the confirmation request from a third user and a proof proving that the third user is entitled to reply to the confirmation request;

and a recording module: recording a reply to the confirmation request;

and a determination module: determining whether the proof of the confirmation request is acceptable;

and a reporting module: in response to determining that the proof is acceptable, the reply is indicated as valid.

10. A non-transitory computer readable medium storing instructions which, when executed by a processor of a device, cause the device to perform the method of any of claims 1 to 7.