Identity verification protocol using blockchain transactions

Abstract

A method of providing a credential enabling a second party to verify an identity of a first party is proposed.SOLUTION: The first party is associated with a first public key registered with a third party. One or more first credentials are provided to a second party. A request transaction is obtained that includes a) an input including a signature generated based on a respective private key of the third party, and b) an output locked to a second public key of the first party. The second public key is based on the first public key. A confirmation transaction is generated. The confirmation transaction includes an input referencing the output of the request transaction and a signature generated based on a private key corresponding to the second public key of the first party. The confirmation transaction is sent to a node of the blockchain network for inclusion in the blockchain.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present disclosure relates to a method for verifying the identity of a party using a blockchain transaction. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which a replicated copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain includes a chain of data blocks, each containing one or more transactions. Each transaction may point to a preceding transaction in a sequence that may span one or more blocks. Transactions may be submitted to the network for inclusion in a new block by a process known as "mining," which involves multiple mining nodes each competing to perform a "proof of work," i.e., solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Traditionally, transactions in a blockchain are used to transfer digital assets, i.e., data that acts as a store of value. However, blockchains can also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data in the output of a transaction. Modern blockchains increase the maximum amount of data that can be stored within a single transaction, allowing for the incorporation of more complex data. For example, this can be used to store electronic documents or even audio or video data on the blockchain.

[0004] Each node in the network can play any one, two, or all three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions throughout the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store their own copies of mined blocks in the blockchain. To record a transaction in the blockchain, a party sends the transaction to one of the nodes in the network to be propagated. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor mined into a block. Assuming the transaction is validated and thereby accepted onto the blockchain, additional user data remains stored at each of the nodes in the P2P network as an immutable public record.

[0005] Multi-factor authentication (MFA) is increasingly being deployed in various systems that require verification of individuals or entities attempting to access the system. For example, MFA may be used when attempting to access an online bank account. MFA is a verification protocol in which an entity seeking access to a system is required to provide multiple authentication methods, usually from independent categories of credentials. Typically, the first factor is a password, and the second factor can range from biometric data to SMS text. These MFA methods are expected to increase the security level of the systems in which they are utilized. Summary of the Invention

[0006] Two-factor authentication (2FA) refers to a type of MFA in which two different forms of credentials are required to verify, or authenticate, a user's identity. For 2FA, SMS texts are commonly used. In such implementations, after submitting a password, the user receives an SMS text containing a specific code. The user then uses this code as the second authentication factor. The security premise of such systems is that a malicious actor is unlikely to have access to a target's SMS phone and / or text (in addition to the target's password).

[0007] However, despite the widespread incorporation of 2FA into verification protocols, problems and vulnerabilities exist in such 2FA designs. For example, SIM swap opportunities allow attackers to steal a target's phone number, thereby enabling them to intercept SMS messages and thus obtain authentication codes.

[0008] Therefore, there is a need for improved, more secure protocols that address current issues with multi-factor authentication, particularly protocols that are not vulnerable to interception of authentication codes by attackers attempting to steal an individual's identity.

[0009] According to one aspect disclosed herein, there is provided a method for providing credentials that enable a second party to verify the identity of a first party, the first party being associated with a first public key, the first public key being registered with a third party, the method including: providing the one or more first credentials to the second party; obtaining a request transaction, where the request transaction is sent to one or more nodes of a blockchain network, the request transaction being a blockchain transaction including: a) an input including a signature generated based on a respective private key of the third party; and b) an output locked to a second public key of the first party, the second public key being based on the first public key; generating a confirmation transaction, where the confirmation transaction is a blockchain transaction including an input referencing the output of the request transaction and the signature generated based on a private key corresponding to the second public key of the first party, causing the confirmation transaction to be sent to the one or more nodes of the blockchain network for inclusion in the blockchain.

[0010] Due to the cryptographic properties of a public-private key pair, only a party with access to the correct private key can generate a verifiable signature using the corresponding public key registered to a third party. The signed confirmation transaction thus serves as a further (e.g., second) credential (or authentication factor) that can be used to verify the identity of the first party. Because the request transaction has an output locked to the registered public key, only the first party can generate a transaction (the confirmation transaction) that unlocks (i.e., spends) that output. Any party can therefore verify the identity of the first party by checking to see if the first party generated the confirmation transaction. If a party cannot generate the confirmation transaction, they do not have access to the correct private key and therefore are not the first party.

[0011] Note that in order to register its public key with a third party, the first party does not need to share its private key (hence the word private). In fact, the first party does not need to share its private key with any other party. Therefore, the provided method does not rely on the sharing of any authentication codes or the like, and does not provide an attacker with the opportunity to intercept such codes and use them to masquerade as the first party.

[0012] The method may be used as part of a 2FA protocol where the signed confirmation transaction is the second credential (or authentication factor), but more generally, the method may be used as any MFA protocol where the signed confirmation transaction is the nth credential.

[0013] As an illustrative example, a user (first party) may be a customer of a merchant (second party) and may have registered their public key with their bank (third party). When attempting to make a purchase from the merchant, the customer provides the merchant with first credentials, such as credit card information, name and address, contact number, etc. The merchant may ask the bank to verify the user's identity, and the bank generates a request transaction payable to the public key registered by the first party. The public key may be registered as part of the bank's know-your-customer (KYC) protocol. The user obtains the request transaction, for example, by scanning the blockchain, and then generates a signed confirmation transaction. Once the bank verifies that the confirmation transaction is signed with a signature that only the first party can generate if it has the private key corresponding to the registered public key, it notifies the merchant that the user with whom it is transacting is indeed the first party. The merchant and user can then continue with the transaction, such as purchasing a good or service.

[0014] As another example, a user (first party) may be attempting to access their email account hosted by an online provider (second party). The user first provides a username and password, and in response, a request transaction is submitted to a node in the blockchain network. The request transaction may be generated by the online provider (in which case the third party is the second party) or may be generated by a trusted third party. Once a signed confirmation transaction is generated, the user is granted access to their email account.

[0015] According to another aspect disclosed herein, there is provided a method for verifying the identity of a first party, the first party being associated with a first public key, the first public key being registered with a third party, the method including: receiving a request to verify the identity of the first party; generating a request transaction, where the request transaction is a blockchain transaction including: a) an input including a signature generated based on a respective private key of the third party; and b) an output locked to a second public key of the first party, the second public key being based on the first public key; causing the request transaction to be sent to one or more nodes of a blockchain network for inclusion in the blockchain; and determining whether a confirmation transaction has been sent to the one or more nodes of the blockchain network for inclusion in the blockchain, where the confirmation transaction is a blockchain transaction including an input referencing the output of the request transaction and the signature generated based on a private key corresponding to the second public key of the first party.

[0016] As described above, the output of a request transaction is locked to a registered public key. For example, the output can be a P2PKH (pay-to-public-key-hash) output, which requires that the input of a spend transaction include the registered public key and a signature generated using the private key corresponding to the registered public key. Only the first party has knowledge of the private key required to correctly generate such an input. Thus, a party (e.g., a second party or a third party) can verify the identity of a user who reports themselves as the first party by determining whether a confirmation transaction using the request transaction has been submitted to the blockchain network. Note that, as described below, neither the request transaction nor the confirmation transaction must be recorded on the blockchain in order for the first party's identity to be verified.

[0017] In some cases, the second party may use an independent third party (e.g., a trusted third party) as part of the protocol to verify the party's identity. In other cases, the second party may itself be the third party that registers the first party's public key. [Brief explanation of the drawings]

[0018] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of another system for implementing a blockchain. [Figure 4] FIG. 1 is a schematic block diagram of a portion of the node software for processing transactions according to the node protocol of the output-based model. [Figure 5] FIG. 1 is a schematic block diagram of a system for verifying the identity of a party using blockchain transactions. [Figure 6] FIG. 1 is a schematic block diagram of another system for verifying the identity of a party using blockchain transactions. [Figure 7] FIG. 1 is a sequence diagram of an exemplary method for verifying the identity of a party using a blockchain transaction obtained from a blockchain. [Figure 8] FIG. 10 is a sequence diagram of another exemplary method for verifying the identity of a party using a blockchain transaction obtained from a blockchain. [Figure 9] FIG. 1 is a sequence diagram of an exemplary method for verifying the identity of a party using blockchain transactions retrieved from a memory pool (mempool) of transactions. [Figure 10] 1 shows a schematic diagram of a chain of unconfirmed transactions in a mempool. [Figure 11] 10 illustrates a schematic of a double spend attempt on a transaction in a mempool. [Figure 12] 1 illustrates schematically how a mempool can function as a communication medium. DETAILED DESCRIPTION OF THE INVENTION

[0019] Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for generally implementing a blockchain 150. The system 100 includes a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer's computing equipment, with different ones of the nodes 104 belonging to different peers. Each node 104 includes a processing unit comprising one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0020] The blockchain 150 includes a chain of data blocks 151, with a respective copy of the blockchain 150 maintained at each of multiple nodes in the P2P network 160. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the amount of digital assets belonging to a user 103 that the output is cryptographically locked (requiring that user's signature to be unlocked and thereby redeemed or spent). Each input points to the output of a previous transaction 152, thereby linking the transactions.

[0021] At least some of the nodes 104 assume the role of forwarding nodes 104F, which forward and thereby propagate transactions 152. At least some of the nodes 104 assume the role of miners 104M, which mine blocks 151. At least some of the nodes 104 assume the role of storage nodes 104S (sometimes called "full copy" nodes), each of which stores a respective copy of the same blockchain 150 in its respective memory. Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a forwarding node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0022] For a given current transaction 152j, the input (or each input) contains a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "spent" in the current transaction 152j. In general, a preceding transaction can be any transaction in the pool 154 or any block 151. While a preceding transaction 152i must exist and be validated for the current transaction to be valid, a preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or transmitted to the network 106. Thus, "preceding" herein refers to something that precedes it in the logical sequence linked by a pointer, not necessarily to the time of creation or transmission in the time sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i is also referred to as an antecedent transaction or a predecessor transaction.

[0023] The input of the current transaction 152j also includes the signature of user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to new user 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to new user 103b, as defined in the output of the current transaction 152j. In some cases, a transaction 152j can have multiple outputs to divide the input amount among multiple users (one of which can be the original user 103a to provide the change). In some cases, a transaction can also have multiple inputs to combine amounts from multiple outputs of one or more preceding transactions and redistribute them into one or more outputs of the current transaction.

[0024] The above may be referred to as an "output-based" transaction protocol, and sometimes as an unspent transaction output (UTXO) type protocol (where outputs are referred to as UTXOs). A user's total balance is not defined by any one number stored in the blockchain; instead, the user needs a special "wallet" application 105 to collate the values ​​of all of that user's UTXOs, which are scattered across many different transactions 152 in the blockchain 151.

[0025] An alternative type of transaction protocol, as part of an account-based transaction model, may be referred to as an "account-based" protocol. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in a sequence of past transactions. The current state of every account is stored and constantly updated by miners separately from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called its "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, optional data fields in a transaction may also be signed. This data field may point to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0026] Using any type of transaction protocol, when a user 103 wishes to complete a new transaction 152j, the user sends the new transaction from the user's computer terminal 102 to one of the nodes 104 of the P2P network 106 (which today is typically a server or data center, but could in principle be another user terminal). The nodes 104 check whether the transaction is valid according to a node protocol applied at each of the nodes 104. The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 and collectively form a transaction model. The node protocol typically requires the nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may involve checking that the user's cryptographic signature included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i used by the new transaction, which typically includes at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the new transaction's input points. In some transaction protocols, the condition may be defined at least in part by custom script included in the input and / or output. Alternatively, the condition may be fixed solely by the node protocol, or by a combination of these. In either case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106.At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, and forwarding the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of nodes 104.

[0027] In an output-based model, the definition of whether a given output (e.g., UTXO) is spent is whether it has been validly redeemed by the input of another prior transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transition 152i that it attempts to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain. This prevents double-spending, where a user attempts to spend the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because transaction ordering is defined, account balances are always in a single, defined state.

[0028] In addition to validation, at least some of the nodes 104M also compete to be the first to create a block of transactions in a process known as mining, which is supported by "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a certain, predetermined number of leading zeros. A property of a hash function is that it has an unpredictable output for its input. This search, therefore, can only be performed brute force, consuming a significant amount of processing resources at each node 104M attempting to solve the puzzle.

[0029] The first miner node 104M to solve the puzzle publishes it to the network 106, providing a proof of its solution that can later be easily checked by other nodes 104 in the network (given the solution to the hash, it is easy to check that the hash output satisfies the condition). The pool of transactions 154 for which the winner solved the puzzle is then recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 functioning as storage nodes 104S, based on checking the winner's published solution at each such node. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. Proof of work helps reduce the risk of double spends because it takes a lot of effort to create a new block 151, and mining nodes 104M are incentivized to avoid including double spends in their blocks because blocks containing double spends are likely to be rejected by other nodes 104. Once created, blocks 151 cannot be modified because they are recognized and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, this provides an immutable public ledger of transactions.

[0030] Note that different miners 104M competing to solve the puzzle at any given time may be doing so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they began searching for a solution. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n, and the current pool 154 of unmined transactions is updated. Miners 104M then continue competing to create blocks from the newly defined unmined pool 154, and so on. There are also protocols for resolving any "forks" that can occur if two miners 104M solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to propagate. In essence, whichever prong of the fork grows the longest results in the final blockchain 150.

[0031] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that suddenly creates a new amount of digital assets (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). The winning node is therefore said to have "mined" a certain amount of digital assets. This special type of transaction is sometimes referred to as a "producing" transaction. It automatically forms part of the new block 151n. This reward incentivizes miners 104M to participate in the proof-of-work competition. Often, a regular (non-producing) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the winning miner 104M who created the block 151n containing that transaction.

[0032] Due to the computational resources involved in mining, typically at least each of the miner nodes 104M takes the form of a server including one or more physical server units, or an entire data center. Each forwarding node 104M and / or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 can take the form of a user terminal or a group of user terminals networked together.

[0033] The memory of each node 104 stores software configured to execute on the node's 104 processing unit to perform its respective one or more roles and process transactions 152 in accordance with the node protocol. It will be understood that any action attributed to a node 104 herein may be performed by software executing on the respective computing device's processing unit. Additionally, the term "blockchain," as used herein, is a generic term generally referring to this type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0034] Also connected to the network 101 are computer devices 102 for each of multiple parties 103 acting as consuming users. These act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice, and the second party 103b will be referred to as Bob; however, this is not intended to be limiting, and it will be understood that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0035] The computing equipment 102 of each party 103 includes a respective processing unit including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 includes memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to execute on the processing unit. It will be understood that any action attributed to a given party 103 herein may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0036] The client application or software 105 may be initially provided to the computer equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example, downloaded from a server, or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0037] The client application 105 has at least a "wallet" functionality. It has two main functions. One of these is to allow each user party 103 to create, sign, and send transactions 152 that are propagated throughout the network of nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that they currently own. In an output-based system, this second function involves reconciling the amounts defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0038] An instance of a client application 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part, through its public visibility). The wallet functionality on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. Each node 104 runs software configured to validate transactions 152 according to the node protocol and, in the case of a forwarding node 104F, to forward the transactions 152 for propagation throughout the network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol works in conjunction with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although the transaction protocol may allow for different subtypes of transactions within it). The same node protocol is used by all nodes 104 in the network 106 (although it may process different subtypes of transactions differently according to rules defined for that subtype, and different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[0039] As noted, the blockchain 150 includes a chain of blocks 151, each of which includes a set of one or more transactions 152 created by the proof-of-work process described above. Each block 151 also includes a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. The blockchain 150 also includes a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the originating transaction) includes a pointer back to a previous transaction to define an order for the sequence of transactions (note: the sequence of transactions 152 can diverge). The chain of blocks 151 stretches all the way back to the originating block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the originating block 153 rather than to a preceding transaction.

[0040] When a given party 103, such as Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using a wallet function in Alice's client application 105) according to the associated transaction protocol. From her client application 105, Alice then sends the transaction 152 to one of one or more forwarding nodes 104F to which Alice is connected. For example, this may be the forwarding node 104F closest or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which are described in more detail below. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0041] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., it is "validated"), any storage node 104S that receives the transaction 152j adds the new validated transaction 152 to a pool 154 in the copy of the blockchain 150 maintained at that node 104S. Additionally, any forwarding node 104F that receives the transaction 152j propagates the validated transaction 152 onward to one or more other nodes 104 in the P2P network 106. Because each forwarding node 104F applies the same protocol, assuming the transaction 152j is valid, this means that it will immediately propagate throughout the P2P network 106.

[0042] Once admitted to pool 154 in the copy of blockchain 150 maintained on one or more storage nodes 104, miner nodes 104M begin competing to solve the proof-of-work puzzle for the latest version of pool 154 that contains new transaction 152j. (Other miners 104M may be trying to solve the puzzle based on older views of pool 154, but whoever gets there first will define where the next new block 151 ends and the new pool 154 begins, and eventually someone will solve the puzzle for the part of pool 154 that contains Alice's transaction 152j.) Once proof-of-work is done for pool 154 that contains new transaction 152j, it immutably becomes part of one of the blocks 151 in blockchain 150. Because each transaction 152 contains a pointer back to the previous transaction, the order of transactions is also immutably recorded.

[0043] UTXO-based model Figure 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following description will be given with reference to an output-based or "UTXO"-based protocol. However, this is not intended to limit all possible implementations.

[0044] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies an amount of a digital asset (store of value). It may also include, among other information, the transaction ID of the underlying transaction. The transaction data structure may also include a header 201 that may include indicators indicating the size of the input field(s) 202 and output field(s) 203. The header 201 may also include the transaction's ID. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner 104M.

[0045] Note that although each output in Figure 2 is shown as a UTXO, a transaction may additionally or alternatively include one or more unspendable transaction outputs.

[0046] Suppose Alice 103a wishes to create transaction 152j to transfer an amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of digital assets locked for Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151, nor that Tx1 is the immediate next transaction in the pool 154. Tx1 can refer to any previous (i.e., earlier) transaction that still has unspent outputs 203 locked for Alice.

[0047] The preceding transaction Tx0 may already be validated and included in the blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the pool 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created and submitted to the network 102 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent” as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified within the transaction (e.g., which transactions point to which other transactions). They may similarly be interchanged with “preceding” and “successor,” or “earlier” and “later,” “parent” and “child,” etc. This does not necessarily imply an order of their creation, transmission to the network 106, or arrival at any given node 104. Nevertheless, a subsequent transaction (a later transaction or "child") that points to a preceding transaction (an earlier transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. It may be buffered for a certain amount of time to wait for its parent or discarded, depending on the node protocol and / or minor behavior.

[0048] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script, which defines the conditions that the unlocking script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be validated and therefore the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines unlocking conditions, which include the condition that the unlocking script in the input of the subsequent transaction contains the cryptographic signature of the party to whom the preceding transaction is locked.

[0049] A lock script (commonly called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S). A lock script specifies what information is needed to use the transaction output 203, for example, the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (commonly called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0050] That is, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice's signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Requires a lock script [Checksig P A ]. [Checksig P A ] is Alice's public key P from her public-private key pair. ATx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0 to identify it among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A What data (or "message") needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0051] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where '||' denotes concatenation, '<...>' means to put data on the stack, and '[...]' are functions that compose the unlock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. In either case, when executed together, the scripts will create a new lock script containing Alice's public key P as contained in the lock script in the output of Tx0. A, to authenticate that the lock script in Tx1's input contains Alice's signature, who signed the expected portion of data. The expected portion of data itself (the "message") must also be included in the Tx0 instruction to perform this authentication. In an embodiment, the signed data includes the entirety of Tx0 (i.e., a separate element specifying the signed portion of the plaintext data need not be included, as it is already inherently present).

[0052] The details of authentication using public-private cryptography are well known to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then given Alice's public key and the plaintext message (the unencrypted message), another entity, such as node 104, can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature on the plaintext version of the message, allowing any holder of the public key to authenticate the signature.

[0053] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), the node 104 considers Tx1 valid. If it is a mining node 104M, this means adding it to the pool of transactions 154 awaiting work of proof. If it is a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in the network 106 so that transaction Tx1 is propagated throughout the network. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO from Tx0 as spent. Note that Tx1 can only be valid if it uses an unspent transaction output 203. If it attempts to use an output that has already been spent by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been spent (already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database marking which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0054] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave behind" a portion of the amount defined in the UTXO as spent; another portion is spent. However, it is possible to split an amount from a UTXO among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use a reminder to give the remainder to herself or to pay another party in the second output of Tx1.

[0055] In practice, because the reward for generating transactions alone is typically not enough to incentivize mining today, Alice also typically needs to include a fee for the winning miner. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner nodes 104M, and therefore, even if technically valid, it will still not be propagated and included in the blockchain 150 (the miner protocol does not force miners 104M to accept transactions 152 if they do not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount pointed to by the input(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 is automatically given to the winning miner 104. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference is automatically awarded to the winning miner 104M. However, it is not necessarily excluded that a miner's fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0056] Note also that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction is not propagated to block 151 or mined.

[0057] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. Nowhere in the blockchain 150 is a number stored defining the given party's 103 total balance. The role of the wallet function in the client application 105 is to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another forward transaction. This can be done by querying the copy of the blockchain 150 stored on one of the storage nodes 104S, e.g., the storage node 104S closest to or best connected to each party's computer device 102.

[0058] Note that script code is often expressed diagrammatically (i.e., not in a precise language). For example, [Checksig P A ] and write [Checksig P A]=OP_DUP OP_HASH160<H(Pa)> OP_EQUALVERIFY may mean OP_CHECKSIG. "OP_..." refers to a specific opcode in a scripting language. OP_CHECKSIG (also called "Checksig") is a script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, the occurrence of the signature ("sig") is removed from the script, but additional requirements, such as a hash puzzle, remain for transactions verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for creating an unusable output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata on the blockchain 150. For example, the metadata may include a document desired to be stored on the blockchain.

[0059] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a specific portion of data. In an embodiment, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific portion of the outputs signed depends on the SIGHASH flag, which is a 4-byte code included at the end of the signature (and is therefore fixed at the time of signing) to select which outputs are signed.

[0060] A lock script is sometimes referred to as a "scriptPubKey," referring to the fact that each transaction contains the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig," referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, any condition or conditions can be defined using a scripting language. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0061] Optional Side Channel FIG. 3 illustrates a further system 100 for implementing a blockchain 150. The system 100 is substantially the same as that described in connection with FIG. 1, except that additional communication functionality is included. Client applications on Alice's and Bob's respective computing devices 102a, 120b each include the additional communication functionality. That is, it allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the direction of either party or a third party). The side channel 301 allows for the exchange of data outside of the P2P network. Such communication is sometimes referred to as "off-chain." For example, it may be used to exchange transactions 152 between Alice and Bob without the transaction being published on the P2P network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Alternatively or additionally, the side channel 301 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0062] The side channel 301 may be established over the same packet-switched network 101 as the P2P overlay network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice's device 1021 and Bob's device 102b. In general, the side channel 301 referenced anywhere herein may include any one or more links over one or more networking technologies or communications media for exchanging data “off-chain,” i.e., separately from the P2P overlay network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, when it is said that Alice and Bob exchange information or particular portions of data, etc., over the side channel 301, this does not necessarily mean that all of these portions of data must be transmitted over the exact same link or the same type of network.

[0063] Node Software FIG. 4 illustrates example node software 400 running on each node 104 of the P2P network 106 in an example UTXO or output-based model. The node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a set of one or more blockchain-related function modules 405. In any given node 104, these may include any one, two, or all three of a mining module 405M, a forwarding module 405F, and a storage module 405S (depending on the node's role or roles). The protocol engine 401 is configured to recognize different fields of a transaction 152 and process them according to the node protocol. Another preceding transaction 152m-1 (Tx m-1Transaction 152m (Tx m ) is received, the protocol engine 401 m The protocol engine 401 also identifies the unlock script in the Tx m Based on the pointer in the input of Tx m-1 It identifies and extracts Tx m-1 from each node's own pool 154 of pending transactions if Tx is not already on the blockchain 150, or m-1 If already on the blockchain 150, Tx from a copy of the block 151 in the blockchain 150 stored on the respective node or another node 104 m-1 In any case, the script engine 401 may extract Tx m-1 The script engine 402 then identifies the lock script in the pointed-to output of the script engine 402 and passes it to the script engine 402.

[0064] Therefore, the script engine 402 executes the Tx m-1 The lock script and Tx m and an unlock script from the corresponding inputs of Tx1 and Tx2. For example, while Tx1 and Tx2 are shown in Figure 4, the same applies to any pair of transactions, such as Tx0 and Tx1. The script engine 402 executes the two scripts together as described above, which includes placing data on and retrieving data from the stack 403 according to the stack-based scripting language being used (e.g., Script).

[0065] By executing the scripts together, the script engine 402 determines whether the unlock script satisfies one or more criteria defined in the lock script, i.e., whether the lock script "unlocks" the included output. The script engine 402 returns the result of this determination to the protocol engine 401. If the script engine 402 determines that the unlock script satisfies one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, it returns the result "false."

[0066] In an output-based model, the result "true" from the script engine 402 is one of the conditions for the validity of a transaction. m the total value of the Digital Assets specified in the output(s) of Tx does not exceed the total value indicated by the input(s) of Tx m-1 There are also one or more further protocol-level conditions evaluated by protocol engine 401 that must also be satisfied, such as that the pointed-to output of has not already been consumed by another valid transaction. Protocol engine 401 evaluates the result from script engine 402 along with one or more protocol-level conditions and executes transaction Tx only if they are all true. m The protocol engine 401 outputs an indication of whether the transaction is valid to the application level decision engine 404. Tx m is actually validated, the decision engine 404 m The mining module 405M may choose to control one or both of the mining module 405M and the forwarding module 405F to perform respective blockchain-related functions with respect to the Tx m and / or the forwarding module 405F adds the Tx mto another node 104 in the P2P network 106. Note, however, that in embodiments, while the decision engine 404 does not choose to forward or mine invalid transactions, this does not necessarily mean that it is obligated to trigger the mining or forwarding of valid transactions simply because they are valid. Optionally, in embodiments, the decision engine 404 may apply one or more additional conditions before triggering one or both functions. For example, if the node is a mining node 104M, the decision engine may choose to mine a transaction only on the condition that the transaction is valid and has sufficient mining fees remaining.

[0067] It should also be noted that the terms “true” and “false” herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, “true” can refer to any state that indicates a successful or positive outcome, and “false” can refer to any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model (not shown in FIG. 4), a “true” outcome may be indicated by a combination of an implicit (protocol-level) validation of the signature by node 104 and an additional positive output of the smart contract (where both individual outcomes are true, the overall outcome is considered to indicate true).

[0068] Identity Verification Protocol 2FA via SMS text is an increasingly popular protocol for enhancing data and system security. Due to ongoing breaches of private and public systems and increasingly stringent data regulations, companies are encouraging or even forcing customers to provide a phone number to protect their data and services through 2FA protocols. After providing an initial factor (e.g., a password login) using this phone number, an SMS containing an alphanumeric value is sent to the customer's phone. The customer then enters this additional value into the system login; if correct, the customer is "authenticated" and granted access. The security of the system is based on the premise that a malicious actor is unlikely to have knowledge of the customer's password and possession of the customer's phone. However, such systems have been found to have several vulnerabilities and shortcomings. One vulnerability is known as "SIM swapping," in which an attacker creates a fake identity document using publicly available information (e.g., name and address) and then uses that identity document at a phone provider's store to impersonate the phone's owner. This allows the attacker to be issued a new SIM card with the owner's phone number, thereby enabling the attacker to intercept SMS texts containing the alphanumeric value.

[0069] The outlined shortcomings are addressed by the proposed identity verification protocol described herein: the use of blockchain eliminates the need for a mobile phone-operated intermediary, and the transparency of blockchain means that if for some reason a malicious actor manages to steal a user's private key, transactions generated using the stolen private key will be immutably documented on the blockchain and can be used as evidence in cases of fraud.

[0070] Another known example of 2FA is a software-based authenticator that implements a two-step verification service, requiring the user (or a malicious actor) to have access to a physical device running the authenticator application. While such authenticators have several advantages over SMS-based protocols, they have drawbacks, such as dependence on the availability of a centralized system and susceptibility to phishing. In contrast, identity verification protocols utilize a decentralized system (a blockchain network), and as a result, the failure of any one node does not render the system unavailable.

[0071] As described below, embodiments of the present disclosure provide an identity verification protocol that allows a first party to use signed blockchain transactions to verify credentials, and that allows a second party and / or a third party to use those signed blockchain transactions to verify the identity of the first party. Embodiments may be used as part of a multi-factor authentication protocol.

[0072] FIG. 5 illustrates an exemplary system 500 for implementing an identity verification protocol. The system includes a first party 501 and a second party 502 (referred to in FIG. 5 as a “user” and an “authorized access person”). The first party 501 operates a respective computing device including a client application configured to generate and transmit blockchain transactions 152 to the blockchain network 106 and retrieve the blockchain transactions 152, for example, from the blockchain 150. For example, the first party may play the role of Alice 103a, operating a wallet application 105a, as described with reference to FIGS. 1-3. In the example of FIG. 5, the second party 502 also operates a respective computing device including a client application configured to generate and transmit blockchain transactions 152 to the blockchain network 106 and retrieve the blockchain transactions 152, for example, from the blockchain 150. In that case, the second party 502 may play the role of Bob 103b, operating a wallet application 105b, as described with reference to FIGS. 1-3. It will be understood that first party 501 and second party 502 may perform some or all of the actions of both Alice 103a and Bob 103b, i.e., in principle, first party 501 and second party 502 may have the same blockchain-related capabilities, and the naming convention is used for illustrative purposes only.

[0073] The second party 502 acts as an "access authority," i.e., controls access to a resource or service. For example, the second party 502 may control access to a physical resource, e.g., a physical product, or a digital resource, e.g., a digital ticket, ballot, token, etc. Examples of services include, e.g., a bank account, an email account, an online account, e.g., an online retail account, a digital streaming service, etc. The second party 502 may be a retailer, a company, a university, a charity, etc. The first party 501 may be a customer, an employee, a student, a donor, etc.

[0074] As an example, the second party 502 may be the owner of a property and the first party 501 may be a vacationer who has paid the second party 502 to access the property for a weekend.

[0075] The first party 501 registers a public key with the second party. As mentioned above, public keys (and public-private key pairs) are well known to those skilled in the art. For example, the first party 501 may register the public key during an initial interaction with the second party 502, e.g., as part of a KYC protocol or account setup.

[0076] As shown in FIG. 5, a first party 501 provides one or more first credentials (1-FA) to a second party 502. For example, the first credential may be a username, password, credit card, name, address, driver's license, passport, memorizable word, key card, etc. The first credential(s) may be provided to the second party 502 over a wired or wireless connection 503, such as the side channel 301 described with reference to FIG. 3. For example, the first party may send the first credential(s) to the second party via email, SMS text, Wi-Fi, Bluetooth, NFC, etc. The first credential(s) may be provided in response to a challenge (or request) from the second party 502, for example, as part of an online purchase or account login. Alternatively, the first party 501 may provide the first credential(s) to the second party 502 without receiving a direct request. For example, continuing with the example where the first party 501 is a vacationer, the first party 501 may present a key card or code (first credential) at the entrance to the property.

[0077] In response to receiving the first credential(s), the second party 502 sends a request transaction Tx rt and submits the request transaction Tx to the blockchain network 106. rt For example, the second party 502 may send a request transaction Tx rt to one or more nodes in the network 106, or a request transaction Tx rt to a different entity that transmits the request transaction Tx to the network 106. rt The request transaction Tx includes at least a first input and a first output. rtmay include additional inputs and / or outputs. The first input includes the signature of the second party 502. That is, the second party 502 signs the transaction with a signature generated using the second party's 502 private key, which may correspond to a public key known to the first party 501 or the general public. The first output is locked to the first party's 501 registered public key, so that it can be unlocked for redemption or use only with a signature generated using the private key corresponding to the first party's 501 registered public key.

[0078] The output can be a P2PKH output that contains a hash of the registered public key (public key hash). To spend a P2PKH output, the input of the spend transaction must contain a public key whose hash (e.g., OP_HASH160) matches the public key hash in the P2PKH output. In other words, the P2PKH output challenges the spender to provide two items, not necessarily in that order: a public key whose hash matches an address in the P2PKH output, and a signature that is valid for the public key and the transaction message.

[0079] A first party 501 receives a request transaction Tx from a second party 502. rt However, preferably, the first party obtains the request transaction Tx by scanning the mempool of the blockchain 150 or the blockchain network 106. rt When a transaction is made on the network, it is sent and held in what is known as a mempool (mempool) until a mining node includes it in the next block 151. Each node on the network 106 runs its own mempool. Request transaction Tx rtmay be obtained by scanning the blockchain or mempool for UTXOs payable to the public key or public key address. In other words, the first party's wallet application scans the blockchain or mempool for transactions payable to its registered public key or hash of the registered public key.

[0080] Request transaction Tx rt Upon obtaining Tx, the first party 501 sends a confirmation transaction Tx ct Generate a confirmation transaction Tx ct is the request transaction Tx rt , i.e., the output of the request transaction Tx locked to the registered public key of the first party 501. rt See the output of Request Transaction Tx rt To use the output of the confirmation transaction Tx ct The input of the request transaction Tx includes a signature generated using the private key corresponding to the registered public key. rt Depending on the type of output, the input may also include a registered public key. This is the case if the output is a P2PKH output. ct includes an output that may be locked to the second party 502, the first party 501, or a different party. Preferably, the output is locked to the second party 502 so that the second party (i.e., the second party's wallet application) can scan the blockchain or mempool for UTXOs payable to the second party's 502 public key (or a hash thereof).

[0081] Confirmation transaction Tx ct In response to obtaining the , and optionally in addition to any further verification steps, the second party 502 grants the first party 501 access to the resource or service.

[0082] Therefore, a confirmation transaction Tx in the blockchain 150 or mempool ct The presence of acts as an additional credential or authentication factor to verify the identity of the first party 501.

[0083] FIG. 6 illustrates another exemplary system 600 for implementing an identity verification protocol. The system of FIG. 6 includes a third party (referred to as a “trusted third party”) 601. In this example, a second party (access authority) 502 still controls access to resources or services, but responsibility for registering the first party's 501 public key and generating request transactions is delegated to the third party 601. The third party 601 may be a certificate authority, e.g., a party entrusted with certifying public keys. For example, the third party may perform a rigorous initial identity check on individuals to link them to their public keys. As an example, the third party 601 may conduct a face-to-face meeting with the first party 501 to check that they match official documents, such as a passport or driver's license.

[0084] In this example, second party 502 may or may not operate a computing device configured to access the blockchain network, while third parties 601 operate respective computing devices that include client applications configured to generate and transmit blockchain transactions 152 to blockchain network 106, as well as retrieve blockchain transactions 152 from, for example, blockchain 150. In effect, third party 601 may perform some or all of the actions attributed to Alice 103a or Bob 103b described with reference to Figures 1-3.

[0085] In the example of FIG. 5, it should be noted that the actions attributed to third party 601 described below may be performed by second party 502, i.e., in this example, second party 502 and third party 601 are the same party.

[0086] A first party 501 provides one or more first credentials to a second party 502, for example, in response to a request for the first credential(s). The second party sends a request (2FA-request) to a third party 601 to verify the identity of a user reporting to be the first party 501. The 2FA-request can be sent over a side channel 504, for example, via the internet or using a blockchain transaction 152.

[0087] The third party 601 sends a request transaction Tx rt As shown above, the request transaction includes an output locked to the registered public key of the first party 501. The difference between this example and the example in Figure 5 is that the request transaction Tx rt The input of the request transaction Tx includes a signature generated by the third party 601. However, this does not exclude that the request transaction may include respective signatures from both the second party 502 and the third party 601. The third party 601 may generate the request transaction Tx rt to the blockchain network 106.

[0088] A first party 501 obtains a request transaction Tx by, for example, scanning the blockchain 150 or mempool. rt Get and confirm transaction Tx ct Generate and confirm transaction Tx ct to the blockchain network 106.

[0089] A third party 601 may obtain a confirmation transaction Tx by, for example, scanning the blockchain 150 or by scanning the mempool of one or more nodes in the network 106. ct Determines whether the transaction Tx has been sent to the blockchain network 106. ctIf the first party's identity has been verified, the third party 601 sends an instruction to the second party 502 informing the second party 502 that the first party's identity has been verified. For example, the third party 601 may send the instruction over a side channel 504 or may send a blockchain transaction 152 containing the instruction to the second party 502. In some examples, the third party 601 may send a confirmation transaction Tx ct (hence the request transaction Tx rt ) is recorded on the blockchain 150.

[0090] In response to receiving the instruction, the second party 502 grants the first party 501 access to the resource or service.

[0091] Figure 7 shows an exemplary sequence diagram for verifying the identity of a first party 501. Figure 7 shows how the first party may (but need not) include two different users: "User A" 701a, operating a respective wallet application 702a, and "User B" 701b, operating a respective wallet application 702b. If the first party 501 includes a single user, then User A 701a is the same user as User B 701b.

[0092] User A 701a provides one or more credentials to the access authority 502. The access authority sends a request to the trusted third party 601 to verify User A's identity. The trusted third party 601 stores the request transaction Tx in the blockchain 150 locked to User B's public key. rt User B's wallet application 702b receives the request transaction Tx from the blockchain 150. rt and notifies User B 701a of a request to provide the second credential. User B then uses wallet application 702b to perform a confirmation transaction Txct and wallet application 702b generates a confirmation transaction Tx ct The trusted third party 601 sends the confirmation transaction Tx ct and sends an indication to the access authority 502 that the first party's identity has been verified. The access authority 502 then grants User B 701a access to the resource or service. In this example, User B 701b verifies the identity of User A 701a. For example, User A may be a child who wants to make a purchase from a merchant or access content on a streaming service, and User B may be a parent who can first determine if the purchase or access is appropriate and then verifies the child's identity. Preferably, however, User A is User B, and User A provides a confirmation transaction to verify his or her identity.

[0093] As an optional feature, the output of a request transaction locked to the public key of a first party may additionally be locked to the public key of the party that generated the request transaction, i.e., the second party 502 or the third party 601. In that case, the output is a multi-signature output. A multi-signature (also known as a multi-sig) output challenges the input of the spend transaction to include a signature corresponding to n-of-m public keys in the multi-sig output. Thus, in these examples, the output may be unlocked (i.e., spent) by the first party 501. The output may alternatively be unlocked by the second party 502 or the third party 601 (depending on which party generated the request transaction). For example, if the second party 502 generated the request transaction, the output may be a 1-of-2 multi-sig output that can be unlocked independently by the first party 501 or the second party 502. Note that once an output is unlocked (i.e., spent) by one of the parties, it cannot be unlocked (i.e., double-spended) by the other party. When a first party 501 unlocks a multi-sig output, the spend transaction is a confirm transaction. When a second party 502 or a third party 601 unlocks a multi-sig output, the spend transaction is a cancel transaction. A cancel transaction allows the second party 502 or a third party 601 to remove a request transaction from the UTXO set, for example, if a period of time has passed since the request transaction was submitted to the network 106.

[0094] As another optional feature, to enhance the privacy of the first party 502, the first party 502 can register the first public key with the second party 502 or third party 601, and the second party or third party can lock the output of the request transaction to a second public key generated based on the first public key. The second public key is generated in a predetermined manner known to both the first party 501 and the second party 502 or third party 601. This allows the first party 501 to scan the blockchain 150 or mempool for the second public key or its hash to obtain the request transaction. For example, the first party 501 may generate a pseudo-random number and share it with the second party 502 or third party 601, or vice versa. The pseudo-random number may be combined with the first public key to generate the second public key. Depending on the public key scheme used, for example, if an ECDSA scheme is used, the pseudo-random number may first be multiplied by a generation point. The pseudo-random number may be shared between the parties using a Diffie-Hellman exchange or a variant thereof. When the first party 501 subsequently interacts with a second party 502, for example to gain access to another resource or service, the second party or third party may apply the same pseudo-random number to the second public key to generate a third public key and lock the output of subsequent request transactions to the third public key.

[0095] Another optional feature is the request transaction Tx rt The challenge is the use of a challenge in the output of the confirmation transaction Tx to include a given response. ct This challenge is then passed to the confirmation transaction Tx ct Note that this is in addition to the requirement that the input of includes the signature of the first party 501.

[0096] First, the first party 501 may send a message to the second party 502, or the second party 502 may send a message to the first party 501. In some examples, the first party 501 and the second party 502 may jointly generate the message by exchanging information. The message may include details of the identity verification request, such as information about the resource or service the first party 501 is trying to access, time and / or date information, etc. In general, the message may include any form of information. In some examples, the message includes a pseudo-random number used to generate the second public key. The message may be sent in encrypted form, in which case the first party 501 and the second party 502 must know or share a decryption key. Methods for sharing a decryption key are well known to those skilled in the art. One such method is a Diffie-Hellman exchange.

[0097] The first party 501 sends a request transaction Tx rt When you get the request transaction Tx rt may determine whether to include the message in its original form (i.e., as plaintext) or in its encrypted form (e.g., as ciphertext). Alternatively, the first party 501 may rt may determine whether X contains a hash (or multihash) of the message in its original form or in encrypted form. A multihash is the result of applying a hash function to a message more than once. Note that a particular hash function may itself hash a message multiple times. In general, applying a multihash function, e.g., a double hash function, may involve applying a first hash function one or more times, followed by applying a second hash function one or more times, where the first and second hash functions may be the same or different hash functions. Additionally, the first hash function and / or the second hash function may themselves apply a hash function one or more times. In the following, we use the notation H to refer to applying a double hash function to a message X.2 (X) is used, where H 2 (X)=H A (H B (X)) and H A and H B may be the same or different hash (or multi-hash) functions. As an example, the hash function H160 is itself a hash function that utilizes two different hash functions, RIPEMD160 and SHA256, i.e., hash160(X) = RIPEMD160(SHA256(X)).

[0098] The first party 501 sends a request transaction Tx rt A confirmation transaction Tx is generated if and only if it contains the expected message or the expected hash of a message (which may be a multihash). ct Preferably, the first party 501 generates a request transaction Tx rt Confirm transaction Tx only if it contains a double hash of the message ct A third party 601 may generate a request transaction Tx rt , the second party 502 shares the message or its (multi)hash with the third party 601.

[0099] Request transaction Tx rt The output of may include an expected message or an expected hash of the message (which may be a multihash). Preferably, the output is a confirmation transaction Tx ct The input of a transaction contains a challenge that requires knowledge of a message to unlock that output. For example, the output may contain a hash puzzle. A hash puzzle takes an input value, applies a hash function to the input value, and compares it to a predetermined hash. If the hash of the input value matches the predetermined hash, a value such as 1 or "true" is output. Including a hash puzzle in a transaction output requires that the input of the spending transaction contain the exact input value (or preimage) that hashes to the predetermined hash.

[0100] As an example, request transaction Tx rt If the output of contains the hash of the message, confirm the transaction Tx ct The input of the request transaction Tx must contain the message itself. rt If the output of contains the double hash of the message, then the confirmation transaction Tx ct The input of must contain the hash of the message. In general, a confirmation transaction Tx ct The input of the request transaction Tx rt It is required to include pre-images of the (multi)hashes included in the output of

[0101] The following example illustrates the use of an identity verification protocol in a two-factor authentication system. In this example, a user is in the process of purchasing an item (hereafter referred to as a "sale transaction") and is expected to sign a blockchain transaction indicating that they grant permission to proceed with the credit card transaction. After generating such a signed transaction, the credit card company and / or business is expected to proceed with completing the sale. The sale involves the use of a payment card for fiat currency, and the first credential (or factor) is the payment (credit or debit) card itself (or at least the associated number).

[0102] Preferably, several important aspects must be considered when implementing an MFA system: Efforts must be made to prevent malicious actors from compromising the system or causing undesirable consequences; Individuals often, if not most, prefer not to have details of their financial transactions in the public domain; It is desirable for the 2FA process to be completed in a short time; Finally, some transparency may be desired for audit purposes in case of discrepancies between the parties.

[0103] A single design 2FAB solution may not be able to fully meet each of the above criteria simultaneously, so a basic design is presented, followed by additional designs that target the aforementioned considerations.

[0104] The following acronyms are used in the examples below: PF1 701a (e.g., first party 501) is the individual seeking to pay for goods or services. This can include a person in a store bringing goods to a cash register or a person making an online purchase from an internet-enabled device. WF1 702a is PF1's blockchain wallet. This wallet is responsible for accessing and submitting transactions to the blockchain 150 on behalf of PF1. WF1 can also compute hashes of strings / text, as well as store and record these hashes and associated text. Enterprise 703 (e.g., second party 502) is the company to which PF1 owes payment for goods and services. Bank 704 (e.g., third party 601) represents the institution that issues, controls, and manages the use of credit / debit cards. PF2 701b is the individual responsible for signing the verification transaction representing the second factor. PF2 may be the same person as PF1. In fact, this is a desirable option, with the same individual attesting to the first and second factors. However, PF1 and PF2 are not necessarily the same individual. For this reason, PF1 and PF2 are represented throughout WP as having their own identities, accounting for cases where they are not the same person. WF2 702b is PF2's blockchain wallet. This wallet is responsible for accessing and submitting transactions to the blockchain on behalf of PF2. WF2 can also observe the blockchain for any 2FA requests from the bank and then communicate this request to PF2.

[0105] To facilitate the design of the 2FA system, the following assumptions are made. First, when a credit card is granted by a credit card company or bank 704, the individual registers a public key (e.g., an ECDSA public key). This public key is tied to the individual's bank account. If the user or bank requires it for security or other reasons, the user can register a new public key with the bank (replacing the previous public key). The second assumption is that when a credit card is granted by the bank 704, the individual and the bank mutually agree on a secret value S that the bank 704 will utilize if there is a need / request to encrypt sales transaction data on the blockchain. This secret S can be securely generated and exchanged between the credit card holder and the bank 704 using the Diffie-Hellman protocol and is tied to the cardholder's account. If the user or bank 704 believes that the previous S has been compromised for security or other reasons, the user can re-engage with the bank 704 to generate a new secret value S (replacing the previous secret value).

[0106] An exemplary sequence diagram for a 2FA system is shown in Figure 8. The first three steps (top to bottom) represent the interaction between PF1 and business 703 when a person decides on goods and services. Here, PF1, after deciding on the items needed, presents this list to business 703 in the form of a formal purchase order or other format. Business 703 constructs an invoice or bill that is communicated to PF1 (this invoice is expected to include the business's identifying information). Once PF1 is satisfied with the invoice details, PF1 provides business 703 with its necessary credit card details. Note that the purchase order, invoice, and credit card do not necessarily have to be physically presented to the other party; they can be communicated using electronic devices such as a card reader, cash register, or mobile phone. After business 703 obtains the credit card information, the cashier constructs a message, e.g., a formal "Sales Transaction Digital Representation" (STDR). This can be a combination of the invoice and PF1's credit card information. Business 703 generates a transaction summary (i.e., hash) H(STDR) and communicates it to PF1. PF1 must possess a computing device, e.g., a smartphone, that is capable of checking whether the H(STDR) value is correct. This function can be performed by WF1 available on the smartphone. Assuming H(STDR) is calculated correctly, the wallet keeps a record of this hash and the STDR itself in anticipation of later 2FA requests.

[0107] Assuming PF1 verifies the H(STDR) value, the company 703 can proceed with processing the user's credit card. The company 703 passes the STDR information to PF1's bank 704.

[0108] The bank 704 validates the information (e.g., business identifier, credit card information, STDR format, etc.) and retrieves the currently registered public key (P CC =v CC G) is taken out. Here, v CCis the private key and G is the generation point. After the validation, the bank 704 generates a double hash H(·) of the STDR using a hash function such as SHA256. 2 (STDR) and submit it to the blockchain as a 2FA request transaction (Tx rt ), where the output of the transaction (labeled Output-2FA for illustrative purposes) is "locked" using a double hash. rt is a transaction that is a formal request by the bank 704 for a second authentication factor for a sales transaction. The second factor being "required" is the P CC In order to use the output-2FA described above, this digital signature must be present in the input script of the transaction that uses the output. rt Examples are shown in the table below: [Table 1]

[0109] Tx rt For , the input for the transaction is a public key P that is expected to be known and trusted by all stakeholders in the proposed system. Bank =v bank The transaction is signed by the bank 704 using G. The transaction has two outputs, the first is the output - 2FA and the second is a non-spendable (e.g., OP_RETURN) output. The non-spendable output is intended to store metadata related to the transaction. There are alternative ways to store metadata within a transaction other than the OP_RETURN output. The OP_RETURN output provides an example of metadata that may be included within a transaction. These are described in the table below: [Table 2]

[0110] Output − In case of 2FA, this is protected by a locking script reproduced below.

number

[0111] The first half of this script is H(STDR) 2 The second half of the pre-image is the ECDSA signature Sig(P CC ) . Assuming there is a scenario where PF2 is unaware of the 2FA request or does not want to confirm the transaction (for example, because it does not remember the sales transaction and does not approve it), then the request transaction Tx rt can be modified as follows: One way is for the bank 704 to rt The purpose of this is to allow PF2 to have the option to use output-2FA. After a period of time, for example at the bank's discretion, if PF2 has not used output-2FA (i.e., provided a second authentication factor), bank 704 can "refund" output-2FA to itself. Thus, the locking script for output-2FA is adjusted to allow both bank 704 or PF2 to unlock the output.

number

[0112] As shown in the script above, this is done by taking two public keys P Bank or P CCThis can be done by including an m-of-n multisig condition requiring signatures on any of the following: Here, the lock script starts with the number of valid signatures required (m), then lists the set of n public keys to which the m signatures must correspond, then the value n, and the opcode OP_CHECKMULTISIG, which checks whether all m signatures are valid. In this way, the bank 704 can use the output-2FA as needed. After its creation, the transaction Tx rt is submitted to the blockchain by the bank 704.

[0113] Tx rt Once P is successfully mined (i.e., included in block 151 on blockchain 150), PF2's wallet (WF2), which is constantly scanning the blockchain (UTXO) for 2FA requests, eventually notices the existence of the transaction on blockchain 150 and alerts PF2 to the existence of this request. Wallet WF2 then CC Output targeting -2FA, and optionally <2FAB-ID> <Tx rt -ID> is specifically sought.

[0114] Assuming PF2 is PF1 (in a tandem wallet, WF2 could be WF1), the wallet will check that the stored H(STDR) received from the first point of contact between PF1 and the enterprise 703 is a decrypted version of STDR in the OP_RETURN output and H(STDR) in output-2FA. 2 (STDR). If the values ​​match (or don't match) and PF2 wants to proceed with the sale transaction, PF2 selects that option in wallet WF2.

[0115] At the instruction of PF2, WF2 executes transaction Tx ctThis transaction is a 2FA confirmation transaction. This transaction is a formal confirmation that PF2 gives authorization to the bank 704 to complete the sales transaction. [Table 3]

[0116] Tx ct The transaction input is Tx rt The output of 2FA is 2FA. So the unlock script for 2FA is as follows:

number

number

[0117] PF2 is the private key v CC In addition, PF2 must provide H(STDR). PF2's inclusion of this hash value is how PF2 verifies that it is responding to the correct sales transaction it should. Note that if there are any changed characters in the STDR, a completely different hash value will be generated.

[0118] The transaction may include at least one output that returns a y value to the bank 704. A second OP_RETURN output may be used to store necessary metadata, such as a <2FAB-ID> that indicates the transaction is a 2FAB transaction and a <2FAB-ID> that indicates the transaction is specifically a 2FAB confirmation transaction. <Tx ct -ID>. The transaction will be submitted to the blockchain.

[0119] Txct Once successfully mined, bank 704 will verify that its wallet software is Tx ct Since we are constantly scanning blockchain 150 for ct The bank 704 becomes aware of the existence of the bank's public key P Bank and optionally specifically requesting transactions that include output targeting the <2FAB-ID><2FA-ct-ID> tags.

[0120] Bank 704 performs any other non-2FA validation processes necessary, adjusts the user's credit card balance accordingly, and then sends a signed authentication to business 703 that the sales transaction has been approved by bank 704. The authentication may be in the form of a blockchain transaction. Business 703 then provides the goods or services to the user.

[0121] In the example of Figure 8, there is a delay in the time it takes for a transaction to be confirmed on the blockchain 150. For a proof-of-work blockchain, the average time for a transaction to be mined (i.e., included in the blockchain 150) is 10 minutes. Request transaction Tx rt Confirm that the transaction Tx is mined ct This, combined with the fact that the tokens are mined, means that it takes approximately 20 minutes from the initial interaction between PF1 in formulating the details of the sale to the time the customer is entitled to the goods or services, which may be impractical in some situations.

[0122] Nodes in the blockchain network 106 store unconfirmed transactions they receive in a database called the unconfirmed transaction mempool, often simply referred to as the mempool. Not all received transactions are added to the mempool. If a transaction double-spends an input of another transaction already in the mempool, it is dropped. A transaction is also dropped if it is not a standard transaction. When a node receives a new block or mines a block itself, the unconfirmed transaction mempool is updated, removing all transactions contained in the block. As transactions are created, they are relayed to the blockchain network 106 through a small number of nodes. Nodes receiving a new transaction check that it is valid and that it is not a double-spend of a transaction already in the mempool. If the transaction passes the check, it is relayed to other nodes in the network; if it does not, it is dropped. The mempool essentially serves as a temporary store for transactions awaiting confirmation in the blockchain. It is maintained by nodes in the blockchain network 106, which check the validity of transactions (including formatting and double-spending). Each node maintains a copy of the mempool, passes new valid transactions to other nodes, and accepts valid transactions from other nodes into its version of the mempool.

[0123] Considering that this validation process is performed by each node for transactions in its respective mempool, the existence of a transaction in multiple mempools can be considered to indicate sufficient, though not complete, validity of the transaction. The validity of a transaction in a mempool is particularly applicable to proof-of-work blockchains, where the first (valid) transaction broadcast is the one included in the next block. Given that transactions are uploaded, validated, and broadcast across nodes very quickly—almost instantaneously—the time between the payer sending a transaction and the recipient "seeing and accepting" the transaction is dramatically reduced if the intended recipient of the payment is willing with a sufficient level of confidence to accept the transaction in the mempool as valid (despite not being mined). Mempools not only store valid transactions that use the UTXOs of mined transactions, but also store and accept as valid transactions that use the outputs of transactions that are in the mempool but not yet mined. This can create a chain of transactions in a mempool, where each transaction uses the output(s) of the previous transaction, and the first transaction is the only transaction that uses the outputs of a mined transaction. Currently, this chain can be as long as 25 transactions.

[0124] Figure 9 shows a sequence diagram of a modified 2FA protocol utilizing a mempool. In this example, WF2 scans the mempool 901 (and the blockchain 150) and alerts PF2 if there is a confirmation request for PF2. If PF2 is willing to provide the second authentication factor, PF2 then sends the transaction Tx rt Output of - Confirmation transaction Tx using 2FA ct PF2 submits the transaction to the mempool.

[0125] The bank wallet scans the mempool for such 2FA confirmed transactions, and the bank 704 ct If indeed exists in the mempool for the sales transaction, it notifies the business 703 to proceed with the sales transaction. Figure 10 shows a chain of unconfirmed transactions in mempool 901. Figure 11 shows a double spend attempt on a request transaction in mempool 901. A major concern when "accepting" a transaction in a mempool as valid (for an MFA protocol or in general) is the threat of double spend. A double spend occurs when a transaction, e.g., "Trans DS", overlaps with another, e.g., Tx ct This results in Tx ct is considered "invalid" and removed from the node's mempool 901, never to be mined or included in a block.

[0126] However, double spending has proven difficult or impractical to achieve in practice.

[0127] On the other hand, even if a double-spend is successful, this does not pose a problem for MFA protocols. The second factor required for a sales transaction is v cc Signed Tx using ct Bank 704 is in the mempool cc Signed Tx ct If you see that transaction, even if it is not confirmed in a block (due to double-spending or other reasons), PF2 still sees transaction Tx ct This can be considered sufficient confirmation of the second factor. The mempool 901 in this understanding serves as a communication medium for request and confirmation transactions, as shown in Figure 12. For their convenience, the bank 704 may also use the Tx ctA copy of the Tx can be stored in its records and is never mined into the transaction. This is available for audits or disputes. However, in most cases, the Tx rt and Tx ct is mined into the blockchain.

[0128] Some parties (e.g., customers and businesses) may need or desire a level of privacy when conducting sales transactions. In the implementations described above, certain measures are taken to protect customer privacy; for example, the details of the sales transaction (STDR) need not necessarily be included in the transaction; instead, a hashed and / or encrypted version of the sales transaction (STDR) may be used. These measures are desirable given that the blockchain 150 is public and immutable. The output-2FA locking script ensures that the hash H(STDR) is the (Tx ct ) in the input script, 2 A transaction may contain a transaction signature (STDR) (or a unique identifier). If a malicious actor is able to determine the raw STDR, the actor could identify all other sales transactions represented on the blockchain 150 if the STDR is the same. To prevent this, it would be wise to make each STDR unique. In some examples, the STDR consists of one or more of the following information: an invoice (details about what is being purchased), credit card details, and a business ID (information that identifies the business 703, e.g., name, address, registration number, etc.).

[0129] If a customer repeatedly purchases the same item from the same store using the same credit card, there is a risk that the STDR will be the same each time. To distinguish between sales transactions, some unique data can be included in the STDR. In some cases, the invoice for a sales transaction includes a unique identifier, commonly referred to as an "invoice number." This addresses the need for a unique STDR, but only to a certain extent. If the number is simply incremented by a fixed value each time a new sales transaction is created, it is computationally easy for interested parties to identify each new sales transaction that "uses the same card to purchase the same item from the same company 703." This would be ideal if the number were a random number selected from a large enough set with a low probability of duplication. A method for generating a unique STDR hash could be to use the date-time value of the transaction time. However, this faces the same challenge: the date-time is a value that increases in a predictable manner. Therefore, knowing at least one STDR, it is possible to iterate through the date-time and calculate and identify hashes for "uses the same card to purchase the same item from the same company" sales transactions. Using a random number (2FAB_Rand) as the ID for a sales transaction is a preferred option. This may be created by the company 703, as previously described, or may be a random number generated by person PF1. Alternatively, it may be a random number jointly generated with input from both the company 703 and PF1 in an initial interaction. The process of generating and validating 2FAB_Rand may be incorporated into the interaction between PF1 and the company 703, as shown in FIG. 9.

[0130] PF1 and the random value of the company k PF1 and k Bus Consider using it as: 0 <k PF1 ,k Bus where q is a large prime number.

[0131] ​The value 2FAB_Rand can be: 2FAB_Rand=(k PF1 +k Bus )mod q

[0132] Modified STDR R ) values ​​are now modified to be: STDR R =STDR||2FAB_Rand Here, || represents concatenation.

[0133] The 2FAB_Rand value is expected to be stored in PF1's wallet. In some cases, the 2FAB_Rand value may be included in the 2FAB-rt transaction as metadata, e.g., encrypted using the value S.

[0134] In addition to concerns about the uniqueness of STDR, P CC There are also concerns about the uniqueness of the public key. The credit card owner provides the public key P CC Recall that each 2FA transaction registers the same value P CC , an interested (and possibly malicious) party can access P without knowing exactly what was purchased. CC If the identity of the cardholder can be discovered, all purchases made by person PF1 can be easily tracked. A new P CC Considering that it is infeasible to communicate and register the value to the bank 704, CC Other options for utilizing the value may be explored. For example, the 2FAB_Rand value described above may be used to generate a new public key. Assume that all parties have agreed on an elliptic curve and a set of parameters (e.g., the secp256k1 elliptic curve) that includes: G - the base point on the elliptic curve with degree q:q×G=0, and q - a large prime number In that case, PCC The public key can be modified as follows: P * CC =P CC +(2FAB Rand )G =v CC G+(2FAB Rand )G =(v CC +2FAB Rand )G

[0135] Request transaction Tx rt The output of 2FA is the public key P * CC Customer PF1 / PF2 sends a confirmation transaction Tx ct Use this value to create the signature required to successfully submit CC The company 703 is responsible for maintaining knowledge of the 2FAB_Rand to pair with the bank 704. Rand Responsible for communicating with G.

[0136] This disclosure describes an identity verification protocol (e.g., an MFA protocol) that utilizes a blockchain transaction as a second authentication factor. A request for a second authentication factor is expressed in a blockchain transaction, and it is expected that confirmation of knowledge of that second authentication factor will be achieved by the intended recipient submitting a confirmation transaction that uses the output of the request transaction.

[0137] The use of blockchain introduces its own complexities, starting with the long (approximately 10 minutes) wait time before a transaction is confirmed into a block. The protocol addresses this by allowing unconfirmed transactions in the mempool to be considered valid for the purposes of the protocol. This applies to request transactions and confirmation transactions that use the output of an unconfirmed request transaction. Accepting unconfirmed transactions makes the authentication process nearly instantaneous.

[0138] In such a scenario, the blockchain serves as the communication medium for the request and confirmation exchange, and importantly, there is a near-certain probability that both transactions will eventually be confirmed on the blockchain.

[0139] Another concern with using blockchain is privacy. Customers may be uncomfortable with third parties being able to identify their purchases. MFA protocols mitigate these concerns by including the use of a random number that is generated for each unique event (sales transaction). This unique random value is used to disguise the public key to which the 2FA request is being sent, as well as the representation of the event details.

[0140] In addition to mitigating limitations inherent in the blockchain 150, the MFA protocol offers advantages over existing solutions. The fact that the blockchain 150 is a distributed system means it does not rely on the availability of a single point of failure. At the same time, the transparency and immutability of the blockchain 150 means that proof of the 2FA request and confirmation sent exists. Audits related to regulatory agencies, governments, or corporations can easily proceed with any investigation related to MFA confirmation or lack thereof; i.e., a bank cannot deny having sent a request transaction, and PF2 / PF1 cannot deny that a confirmation transaction was signed. A malicious actor cannot surreptitiously provide 2FA confirmation without PF2 / PF1's knowledge. This becomes apparent if a bank or corporation processes a sales transaction without a confirmation transaction signed by PF1 / PF2.

[0141] Although we have described the protocol in terms of sales transactions involving fiat currency, the protocol may be appropriate for other "transactions" that require MFA authentication, such as managing secure access to files or physical buildings. In such cases, the following is considered: - Sales transactions are replaced by general events; - The company is described here as the gatekeeper or access authority; and - A bank is described here as a trusted third party certification authority and is considered to be any entity or system responsible for registering, among other things, the public key of PF1.

[0142] conclusion It will be understood that the above embodiments have been described by way of example only. More generally, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0143] Statement 1. A method for providing credentials that enable a second party to verify the identity of a first party, the first party being associated with a first public key, the first public key being registered with a third party, the method including: providing one or more first credentials to a second party; Obtaining a request transaction, where the request transaction is a blockchain transaction that includes: a) an input including a signature generated based on the respective private key of a third party; and b) an output locked to a second public key of the first party, where the second public key is based on the first public key; generating a confirmation transaction, where the confirmation transaction is a blockchain transaction that includes an input that references the output of the request transaction and a signature that was generated based on a private key that corresponds to the second public key of the first party; and Causing a confirmation transaction to be sent to one or more nodes of a blockchain network for inclusion in the blockchain.

[0144] Examples of the one or more first credentials include a username, password, biometric identifier, phone number, address, a code received via SMS text (from a third party), a payment card (or information thereon), bank details, a memorable word, etc.

[0145] Statement 2. The method described in statement 1, wherein the obtaining includes obtaining the request transaction from a blockchain.

[0146] Statement 3. The method according to statement 1, wherein the obtaining includes obtaining the request transaction from respective memory pools of one or more nodes in the blockchain network, each respective memory pool including a respective set of unconfirmed blockchain transactions.

[0147] Statement 4. The method of any of statements 1 to 3, wherein said providing said one or more first credentials is in response to receiving an identity challenge from a second party.

[0148] Statement 5. The method of any of statements 1 to 4, wherein the causing includes sending the transaction to one or more nodes of a blockchain network.

[0149] Statement 6. A method according to any one of statements 1 to 5, comprising: receiving from or transmitting to a second party at least one of the message and / or a hash of the message; and Determining whether the request transaction includes at least one of a message, a hash of the message, and / or a multihash of the message, wherein generating the confirmation transaction is conditioned on the request transaction including at least one of a preimage of the message, a hash of the message, and / or a multihash of the message.

[0150] Statement 7. The method of statement 6, wherein the output of the request transaction includes a challenge that requires knowledge of the message and / or a hash of the message in order to be unlocked, and the input of the confirmation transaction includes a preimage of the message, a hash of the message, and / or a multihash of the message.

[0151] Statement 8. The method of statement 6 or statement 7, wherein the message includes a first pseudorandom number.

[0152] Statement 9. The method of any of statements 1 to 8, wherein the second public key is generated by combining the first public key with a second pseudorandom number.

[0153] Statement 10. The method of any of statements 1 to 8, wherein the second public key is the first public key.

[0154] Statement 11. The method of statement 8 or statement 9, wherein the first pseudorandom number and / or the second pseudorandom number is based on a third pseudorandom number generated by the first party and a fourth pseudorandom number generated by the second party.

[0155] Statement 12. The method of statement 9 or statement 11, wherein the second pseudorandom number is the first pseudorandom number.

[0156] Statement 13. The method of any of statements 1 to 12, wherein the third party is the second party.

[0157] Statement 14. A method for verifying the identity of a first party, wherein the first party is associated with a first public key, and the first public key is registered with a third party, the method includes: receiving a request to verify the identity of a first party; generating a request transaction, where the request transaction is a blockchain transaction that includes: a) an input that includes a signature generated based on the respective private key of the third party; and b) an output that is locked to a second public key of the first party, where the second public key is based on the first public key; causing the request transaction to be sent to one or more nodes of the blockchain network for inclusion in the blockchain; and Determining whether a confirmation transaction has been sent to one or more nodes of the blockchain network for inclusion in the blockchain, where the confirmation transaction is a blockchain transaction that includes an input that references the output of the request transaction and a signature generated based on a private key that corresponds to the second public key of the first party.

[0158] The request may be a blockchain transaction.

[0159] Statement 15. The method of statement 14, wherein determining whether the confirmation transaction has been sent to one or more nodes of the blockchain network for inclusion in the blockchain includes: Determining whether a confirmation transaction is included in the blockchain.

[0160] Statement 16. The method of statement 15, wherein determining whether the confirmation transaction has been sent to one or more nodes of the blockchain network for inclusion in the blockchain includes: Determining whether the confirmed transaction is included in a respective memory pool of one or more nodes of the blockchain network, where each respective memory pool includes a respective set of unconfirmed blockchain transactions.

[0161] Statement 17. A method according to any one of statements 14 to 16, comprising: Verifying the identity of a first party based on whether a confirmation transaction has been sent to one or more nodes in a blockchain network.

[0162] Statement 18. The method of statement 17, wherein the request is received from a second party, and the method includes: Sending an indication to the second party that the identity of the first party has been verified.

[0163] The instruction may be a blockchain transaction.

[0164] Statement 19. The method of statement 18, wherein receiving the request includes receiving an indication that the first party has provided one or more first credentials to the second party.

[0165] Statement 20. The method of statement 18 or statement 19, wherein the request includes at least one of a message or a hash of a message, and the output of the request transaction includes a challenge that requires knowledge of the message and / or the hash of the message in order to be unlocked.

[0166] Statement 21. The method of statement 20, wherein the message includes a first pseudorandom number.

[0167] Statement 22. The method of any of statements 14 to 21, wherein the second public key is generated by combining the first public key with a second pseudorandom number.

[0168] Statement 23. The method of statement 21 or statement 22, wherein the first pseudorandom number and / or the second pseudorandom number is based on a third pseudorandom number generated by the first party and a fourth pseudorandom number generated by a third party.

[0169] Statement 24. The method of any of statements 14 to 21, wherein the second public key is the first public key.

[0170] Statement 25. The method of any of statements 14 to 24, wherein the output of the request transaction is locked to the first party's second public key or a third party's public key.

[0171] Statement 26. The method according to statement 25, comprising: generating a cancellation transaction, where the cancellation transaction is a blockchain transaction that includes an input that references the output of the requesting transaction and a signature that was generated based on a private key that corresponds to the first party's public key; and causing the cancellation transaction to be sent to one or more nodes of the blockchain network for inclusion in the blockchain.

[0172] Statement 27. The method described in Statement 17 and any statements subordinate thereto, wherein a second party controls access to or ownership of a resource or service, and access to or ownership of the resource or service is granted to a first party based on verification of the first party's identity.

[0173] Examples of resources or services include physical or digital goods, email accounts, social media or other online accounts, streaming services, digital tokens (e.g., tickets or votes), etc.

[0174] Statement 28. The method of any of statements 14 to 27, wherein the second party is a third party.

[0175] Statement 29. Computer equipment comprising: a memory comprising one or more memory units; and A processing device having one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any of statements 1 to 28.

[0176] Statement 30. A computer program embodied on a computer-readable storage and configured to perform the method of any of statements 1 to 28 when executed on a computing device according to statement 29.

[0177] Other variations may be apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is not limited by the disclosed embodiments, but only by the appended claims.

Claims

1. 1. A method of verifying the identity of a first party based on two or more credentials of the first party, wherein the first party is associated with a first public key, the first public key being registered with a third party, and the method being performed by the third party; receiving a request to verify the identity of the first party; generating a request transaction, the request transaction being a blockchain transaction including: a) an input including a signature generated based on the private key of each of the third parties; and b) an output locked to a second public key of the first party, the second public key being based on the first public key; causing the request transaction to be transmitted to one or more nodes of a blockchain network for inclusion in a blockchain; determining whether a confirmation transaction has been sent to one or more nodes of the blockchain network for inclusion in the blockchain; wherein the confirmation transaction is a blockchain transaction including an input referencing the output of the request transaction and a signature generated based on a private key corresponding to the second public key of the first party, such that the confirmation transaction unlocks the output of the request transaction; and the confirmation transaction is a second credential of the first party, for use with one or more first credentials to verify the identity of the first party.

2. determining whether the confirmation transaction has been sent to one or more nodes of the blockchain network for inclusion in the blockchain includes: determining whether the confirmation transaction is included in the blockchain; The method of claim 1 , comprising:

3. determining whether the confirmation transaction has been sent to one or more nodes of the blockchain network for inclusion in the blockchain includes: determining whether the confirmation transaction is included in a memory pool of each of one or more nodes of the blockchain network; wherein each respective memory pool contains a respective set of unconfirmed blockchain transactions.

4. verifying the identity of the first party based on whether the confirmation transaction was transmitted to one or more nodes of the blockchain network. The method of claim 1 , comprising:

5. The request is received from a second party, and the method includes: sending an indication to the second party that the identity of the first party has been verified; The method of claim 4, comprising:

6. The method of claim 5 , wherein receiving the request comprises receiving an indication that the first party has provided one or more first credentials to the second party.

7. 6. The method of claim 5, wherein the request includes at least one of a message or a hash of the message, and the output of the request transaction includes a challenge that requires knowledge of the message and / or the hash of the message in order to be unlocked.

8. The method of claim 7 , wherein the message includes a first pseudo-random number.

9. The method of claim 1 , wherein the second public key is generated by combining the first public key with a second pseudo-random number.

10. 9. The method of claim 8, wherein the first pseudorandom number and / or the second pseudorandom number is based on a third pseudorandom number generated by the first party and a fourth pseudorandom number generated by the third party.

11. The method of claim 1 , wherein the second public key is the first public key.

12. The method of claim 1 , wherein the output of the request transaction is locked to the second public key of the first party or a public key of the third party.

13. generating a cancel transaction, the cancel transaction being a blockchain transaction that includes an input that references the output of the request transaction and a signature that was generated based on a private key that corresponds to the public key of the first party; causing the cancellation transaction to be transmitted to one or more nodes of the blockchain network for inclusion in the blockchain; 13. The method of claim 12, comprising:

14. 5. The method of claim 4, wherein the second party controls access or ownership of a resource or service, and access or ownership of the resource or service is granted to the first party based on the verification of the identity of the first party.

15. The method of claim 1 , wherein the second party is the third party.

16. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units, The memory stores code configured to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any one of claims 1 to 15. Computer equipment.

17. A computer program embodied on a computer readable storage and adapted to perform the method of any one of claims 1 to 15 when executed on a computing device.

Images