Computer-implemented methods and systems for public key infrastructure and identity verification

Abstract

Embodiments provide secure and flexible technical solutions for verifying a user's identity, creating a Web of Trust, and / or implementing a PKI or Web of Trust. Some embodiments may be particularly suitable for use in conjunction with a blockchain. The present disclosure enables a validation entity to apply its own rules, policies, and criteria to the selection and / or combination of identity resources, e.g., documents, from a set of such resources made available by a user. Thus, the user controls which documents are made available to the validation entity, while the validation entity can select which, how many, and what types of resources are acceptable for successfully establishing the user's identity. Access to resources controlled by the validation entity is granted or denied as a result of a user attempting to validate that they are who they say they are based on the resources they provide.

Description

[Technical Field]

[0001] The present disclosure relates to secure and flexible technical solutions for identity verification and validation, creating or improving a Web of Trust, and / or implementing a PKI (Public Key Infrastructure). Some embodiments may be particularly suitable for use in conjunction with a blockchain. [Background technology]

[0002] There are many situations in which an entity (e.g., a natural person, a business, or a computer-based system) needs to prove to another party that it is who it claims to be. Thus, proof and validation of identity have become common everyday activities in today's world. For ease of reference, we will use the term "user" to mean an entity that wishes to prove its identity to another (validating) party.

[0003] One approach to verifying identity is to use a public key infrastructure (PKI), which involves proving ownership of a private cryptographic key in a way that only a legitimate, authentic entity can. For example, a private key is used to encrypt a puzzle, and a validating entity can then decrypt it with the corresponding public key, or digitally sign a resource so that a validator can check the signature. In this way, a PKI provides a "trust service" that can be used to verify that a sender or receiver of data is who they claim to be.

[0004] However, different validation entities may require different types of proof. For example, one organization may require a utility bill and driver's license as proof of an individual's identity, while another organization may require a passport, college diploma, and bank statement. Matching and providing various combinations of proof can be difficult for an entity attempting to prove identity. Furthermore, documents and other proof may expire or become outdated and therefore may need to be invalidated or disregarded as a legitimate source of identity. From the perspective of the validation entity, one or more proof(s) that are deemed sufficient to establish identity must be specified, obtained, and checked. Known approaches to this validation process can be time-consuming and labor-intensive. Therefore, it would be advantageous to provide a solution that enables entities to prove and validate identity in a secure, efficient, and flexible manner. Solutions have now been devised that address at least these technical challenges and provide at least these technical effects. Summary of the Invention [Problem to be solved by the invention]

[0005] Embodiments of the present disclosure aim to provide at least a general purpose identity solution that allows entities, which we call "users" (e.g., individuals or groups of natural persons, legal entities, organizations, or one or more computer-based resources, etc.), to prove their identities to other parties, which we will call "validation entities" for ease of reference. In some embodiments, this may be achieved, or at least facilitated, through the use of blockchain. [Means for solving the problem]

[0006] In some embodiments, this solution incorporates some aspects of an on-chain PKI, but importantly, the disclosed embodiments allow a user to determine and / or create a set of rules and policies regarding identity-related resources (e.g., documents) that they wish to make available to one or more validation entities for the purpose of proving their identity. Additionally or alternatively, the validation entities may apply their own set of rules and policies when selecting identity-related resources in attempting to verify the user's identity.

[0007] A validation entity may be any type of entity (e.g., an individual or group of natural persons, a legal entity, an organization, or one or more computer-based resources) that desires to verify a user's identity. In a preferred embodiment, at least one validation entity can select one or more identity resources from multiple such resources made available to them by the user. This distinguishes the present invention from prior art schemes in which a user selects which identity resources to provide to a validation party, and also from prior art schemes in which a validation party sends a request for a specific type of identity resource. This allows a validation entity to apply its own rules, policies, and / or criteria to the selection of identity resources required for validation purposes. For example, one validation entity may select a utility bill and a driver's license as sufficient proof of identity, while another validation entity may select a passport, birth certificate, and social security number according to the validation entity's predetermined criteria.

[0008] In some embodiments, the validation entity may rank (i.e., weight) identity resources and / or assign predetermined values ​​to resource types. For example, a validator may utilize a points-based approach in which different identity resources are assigned different points or weights depending on their perceived significance or reliability as evidence of identity, and a predetermined number of points may be selected as a threshold for establishing identity. The type and / or number of identity resources selected by the validation entity may then depend on the identity resources made available by the user and requested by the validator. For example, the validation entity may determine that a minimum of 50 points is required to validate a user's identity, with a utility bill worth 25 points and a driver's license worth 30 points. If a user makes available a utility bill and a driver's license, the validation entity's selection of these two identity resources is considered sufficient by the validation entity to establish that the user is who they say they are. On the other hand, another validation entity, e.g., a potential employer, may determine that a college diploma is a required identity resource along with any one of a passport, birth certificate, or driver's license.

[0009] Thus, embodiments facilitate the use of on-chain PKI beyond simple "I have a cryptographic key that I can use to sign something." The present disclosure enables the building of different levels of trust and security using a more fine-grained, yet flexible, approach by allowing a validating third party to choose from multiple identity resources provided by the user.

[0010] In this manner, embodiments of the present disclosure enable the creation of a Web of Trust or PKI based on the provision and use of different attestation sources.

[0011] For clarity, it should be noted that the term "validation" is used in the context of this specification in its traditional sense and with respect to establishing a user's identity, rather than the validation functionality performed by nodes on a blockchain network.

[0012] 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: [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates a schematic of some example transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a schematic diagram of a mock-up of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 1 is a schematic block diagram of some node software for processing transactions. [Figure 5] FIG. 2 is a block diagram illustrating high level blocks of interacting functional blocks in accordance with a preferred embodiment. [Figure 6] 1 is a block diagram illustrating multiple members of a set of digital identity resources and the connections between such members. [Figure 7] 3 is a flow chart illustrating the steps performed by a preferred embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0014] Next, for illustrative purposes, we provide some examples of systems and methods that can be used to implement preferred embodiments of the present disclosure.

[0015] In accordance with exemplary embodiments of the present disclosure, by way of example only, consider a scenario in which an entity, such as a user, desires to provide evidence to at least one third party so that the third party can validate the user's identity and prove that the user is who they claim to be.

[0016] In the following example, we use a scenario in which a user wants to prove their identity in order to open a bank account. Note that this is for illustrative purposes only; a user's identity can be validated for any purpose. Typically, however, identity validation is performed before performing an authorized action, gaining access to some controlled resource (whether physical or electronic, such as a vehicle, building, network account, software, etc.), or performing a controlled service. In our simple example, the controlled service is the provision of a financial account, but any other controlled resource could be substituted for this example.

[0017] 5, exemplary user 51 is a user who wishes to open a bank account, for example, with bank 52. Bank 52 is a validating party, requiring user 51 to prove user 51's identity to bank 52 before bank 52 will allow the user to open a bank account with bank 52. This is because bank 52 needs to know exactly for which party it is opening a bank account in case, for example, user 51 is committing fraud and presents the bank with a name that is different from user 51's actual name while attempting to open the bank account.

[0018] 5 , according to the illustrated example, bank 52 requires user 51 to provide a specific set of official documents to the bank in order for user 51 to properly prove his / her identity to bank 52. User 51 provides a set of official identity-providing resources (e.g., documents) to storage device 53 over a network connection (which may be an Internet connection, a mobile phone connection, or other well-known network connection for allowing data to be exchanged). The set of official identity-providing documents may be, for example, a driver's license in user 51's name, a birth certificate in user 51's name, a passport in user 51's name, a social security card in user 51's name, a bank statement associated with another bank account belonging to user 51, or a college diploma asserting that user 51 graduated from a specified university and obtained a specific degree qualification in a specified subject from the specified university. User 51 stores digital versions of such documents on storage device 53, which may have originally existed in paper form or were always embodied in digital form.

[0019] In FIG. 5, the storage device 53 may be a database, a cloud-based service (there are many such services available), or the storage device may be implemented as a blockchain (more details of which are described herein in conjunction with FIGS. 1-4), while the identity-providing resources may be stored on multiple nodes 104 of a blockchain peer-to-peer network 106 (as shown in FIG. 1).

[0020] A user 51 desires to make several identity resources available to a validating third party 52, and therefore the user 51 generates a set of at least one (but preferably multiple) identity resources, with examples such as those given above (e.g., a driver's license). Each identity resource is a resource or item that is associated in some way with the user. In one or more embodiments, the identity resource is selected, possibly by the user, from multiple resources over which the user has ownership and / or control.

[0021] An identity resource can be any suitable form of identity evidence. Preferably, it is an electronic resource containing data in digital form. For example, it can be an electronic document such as a scan, photograph, PDF, or other electronic capture of a paper-based document. Alternatively, it can be or contain software-generated data, such as a digitally signed resource. An identity resource can be issued or provided by a suitable source, such as, for example, a utility company, a passport office, a licensing agency, a notary public, or a bank.

[0022] After the user selects the set of identity resources they want to provide for verification, the user makes them available to at least one third party. This can be accomplished in any manner appropriate for a particular implementation. Preferably, the identity resources are provided by the user to be stored in storage device 53. As noted above, this can include a database, a blockchain, a cloud-based resource, or the like. The nature or form of the storage device is not limited. For example, in one implementation, the user may make the identity resources available via a website, while in another implementation, the user may upload them to a document resource such as Microsoft SharePoint. The user may share a URL or link to where the identity resources are located with at least one third party.

[0023] In a preferred embodiment, identity resources are managed in storage device 53 by a digital wallet. The digital wallet can be used and accessed by user 51 through an interface or software application (app). In some embodiments, one or more of the identity resources are stored in the user's wallet but registered on the blockchain. This provides the advantage that the registration can be verified in an immutable, time-stamped manner and that the wallet can revoke a particular identity resource, for example, if it expires or becomes stale, or if the user no longer wishes to provide it as proof of identity. This can be achieved by implementing storage device 53 on multiple nodes 104 of a peer-to-peer blockchain network 106, as illustrated in FIG. 1. The digital wallet application can run on top of a software layer that implements blockchain peer-to-peer functionality. For example, the digital wallet application can be built as a smart contract, or the wallet can include a smart contract, that includes business logic code for implementing the wallet functionality.

[0024] In this embodiment, a set of identity resources associated with user 51 may be stored in blocks Bn-1, Bn, etc. of a blockchain 150 running on nodes 104 of blockchain peer-to-peer network 106 of Figure 1. When user 51 decides to add new identity resources to the blockchain or to remove some identity resources from the blockchain, such as when such identities become stale or expire, these identity resources may be added to mempool 154 to await incorporation into blocks 152 of the blockchain. This may be achieved by generating transactions that include these identity resources (or references to them) and then submitting the transactions to the mempool for subsequent incorporation onto the ledger.

[0025] In FIG. 5, user 51 can be considered to be Alice (payer 103a) in FIG. 1, and similarly, validation party 52 in FIG. 5 can be considered to be Bob (payee 103b) in FIG.

[0026] As is known, data stored in the blockchain 150 is immutable, meaning that data cannot be modified by another user without this modification being immediately known to all other users of the blockchain. This is achieved through the use of cryptographic primitives such as hash functions, digital signatures, and encryption. Thus, the set of identity resources that user 51 / 103a adds to the blockchain 150 is securely registered in the storage device 53 / blockchain 150. Due to the properties of hash functions (the result is deterministic and cannot be reversed), this means that it can be easily verified whether the contents of a block have been modified by re-hashing the contents of the block and comparing it with identifiers from a subsequent block, as is known in blockchain technology.

[0027] Preferably, access to storage device 53 and / or the identity resources stored on storage device 53 is controlled so that only authorized third parties (such as validation party 52) can gain access to the identity data. User 51 shares an access control mechanism with at least one third party (e.g., validation party 52) via any suitable means, thereby allowing the at least one third party to access the identity resources in the storage device. User 51 may want to allow multiple third parties to have access to user 51's set of identity resources, and user 51 would then share the access control details with each such third party. For example, user 51 may want to allow other third parties, in addition to bank 52, to gain access to the set of identity resources, such as a law firm (e.g., conducting money laundering checks on user 51 before taking on user 51 as a new client).

[0028] In FIG. 5, user 51 can communicate such access control details directly to validation party 52 via a direct connection 54 (over the network described above), or via storage device 53, over connection 55 between user 51 and storage device 53, and then over connection 56 between storage device 53 and validation party 52.

[0029] Although only one user 51 and one validation party 52 are shown in FIG. 5, multiple users 51 and multiple validation parties 52 are typically included in a typical implementation of the disclosed technology.

[0030] The access control mechanism may be any suitable authorization means, such as a secret identifier, e.g., a password, a PIN, or an encryption key. The access control mechanism may be set to allow only temporary access. For example, it may expire or cease to operate after meeting criteria set by a user. For example, it may expire after a certain period of time, or on a particular date or time, or after being used a predetermined number of times to gain access.

[0031] In a preferred embodiment, each third party (e.g., bank 52 in the example above and any other third parties, such as the law firm mentioned above) is given its own respective access control mechanism. Identity resources may be organized or structured in some way by a user, such that different types of identity resources may be made available to different third parties. For example, identity resources may be formed into a hierarchical structure according to the degree of confidentiality determined by the user to apply to particular resources. For example, a user may consider utility bills and birth certificates to be less sensitive than passport details, which may therefore be considered less sensitive than social security numbers, bank account details, or taxpayer identification numbers. Third parties needing to validate a user's identity may be provided with access control mechanisms that permit access to resources at one or more levels of the data structure. Thus, access permissions may be provided that permit various degrees of access depending on what is determined necessary or appropriate by the user. This may include an assessment of trust made by the user with respect to a given third party. For example, a user may consider a government agency, such as a tax office or passport office, to be more trustworthy than a credit broker who provides a loan for purchasing a car.

[0032] Each user 51 can apply his or her own set of rules or policies to the corresponding set of identity resources stored in the storage device 53. For example, the user 51 can specify a policy that only certain highly trusted third parties 52, such as a government agency, can access the digital representation of the user 51's birth certificate, while a broader set of third parties 52 can access other members of the set of identity resources, such as a PDF scanned copy of the user 51's passport or a scan of the user 51's driver's license. This policy can be specified by sharing different access control mechanisms for different validation third parties 52, as described above, or alternatively, the user 51 can specify a policy for sharing some members of the set of identity resources, which can be encoded as part of a smart contract, in which case the storage device 53 is implemented as a blockchain, as described above. Any other method of encoding a policy can also be used to specify the user 51's particular situation and desires regarding the sharing of identity resources.

[0033] Similarly, each validation party 52 can specify its own set of rules or policies that can be applied to the set of identity resources that at least one user 51 has stored in storage device 53 and shared with each validation party 52. ​​For example, one validation party 52 may request a review of a utility bill (e.g., water bill, electricity bill, etc.) and even a driver's license; if these two identity resources are accessed by the validation party 52, the validation party 52 considers this sufficient to verify the identity of the user 51. On the other hand, another validation party 52 may request a scan of a passport, a college diploma, and a bank statement. Yet another validation party 52 may require that all of the just-mentioned identity resources be checked. Each such validation party 52 can apply its own set of rules or policies to select specific members of the set of identity resources that the user 51 has stored in storage device 53. This set of policies / rules can also be specified by encoding the set of policies / rules as part of a smart contract, in which case storage device 53 is implemented as a blockchain as described above. Any other method of encoding policies can also be used to specify the particular circumstances and desires of user 51 regarding the sharing of identity resources.

[0034] The set of policies / rules described above, as set by the user 51 and the validation party 52, can be implemented in software logic by assigning connections between each member of the set of identity resources, and each of those connections can then be assigned a weighting or ranking depending on the level of importance that the user 51 or validation entity 52 assigns to that pairing of members of the set of identity resources.

[0035] Specifically, a set of identity resources 60 is shown in Figure 6 for a particular user 51, who has decided to share this set 60 with a validation entity (such as validation entity 52) and store it on storage device 53. In the example illustrated in Figure 6, the set of identity resources 60 includes a utility bill 61, a driver's license 62, a passport 63, a university diploma 64, and a bank statement 65.

[0036] In a preferred embodiment, one or more of the identity resources may be cryptographically secured, generated, signed, or encoded by an issuing entity. For example, the issuing entity for a passport may typically be a government passport office, while the issuing entity for a transcript may be a university. The use of cryptography allows the identity of the issuing entity (and therefore the authenticity of the identity resource) to be verified. For example, the issuing entity may use a private key to encode or sign the identity resource or its associated certificate. A public key associated with the private key may be used to decode the resource or certificate or check the signature. In this way, the validity of the identity resource may be proven through the use of a cryptographic key. The association of the public key with a particular issuer may be obtained from a Web of Trust. Additionally or alternatively, the public key may be obtained directly from the issuer or a known representative. In this way, the validation entity can check that the identity resource provided by the user is authentic and has not been forged, tampered with, or altered from its original issued state. This provides an improved level of security for the validation entity.

[0037] A connection 612 between utility bill 61 and driver's license 62 is shown in Figure 6. Similarly, a connection 613 is shown between utility bill 61 and passport 63, a connection 614 is shown between utility bill 61 and college diploma 64, a connection 615 is shown between utility bill 61 and bank statement 65, a connection 634 is shown between passport 63 and college diploma 64, a connection 635 is shown between passport and bank statement, and a connection 645 is shown between college diploma 64 and bank statement 65.

[0038] Each of these connections 612 through 645 may be assigned a weighting (which may be referred to as "points" or "value") so that a particular pairing of identity resources may be ranked according to how important that particular pairing is to policies set by either the user 51 and / or the validation party 52. ​​Alternatively, instead of connections between members of a set of identity resources being weighted, each member of the set 60 itself (61 through 65) may be assigned a weighting. The validator's rules may specify that a combination of identity resources must reach a sufficient number of total "points" for verification of a user's identity to be considered successful.

[0039] If connections are weighted, connection 612 may be given a very high weight, such as 95 (assuming here that ranking is in the range of 0 to 100), if the validating party 52 needs access to utility bill 61 and driver's license 62 for a particular policy that the particular validating party 52 wants to implement. Similarly, for another validating party 52 needing access to passport 63, college diploma 64, and bank statement 65, connections 635, 634, and 645 may be assigned a very high weight, such as 90.

[0040] Similarly, user 51 can assign weights to members of set 60 of identity resources to indicate user 51's preferences / policies / rules regarding the sharing of each member of the set with validation entities. For example, if a low weighting is assigned to a particular connection (i.e., combination) between two members, such as if a weighting of 20 was assigned to connection 612 between utility bill 61 and driver's license 62, user 51 considers these two members of set 60 to be less sensitive and more easily accessible by a wider range of validation parties 52.

[0041] In situations where user 51 is not aware of the policies of each of the potential validating parties 52, user 51 may assign very low weightings to the members (or connections between each of the members) to ensure that each validating party 52 can maximize the enforcement of such validating party's rules or policies. That is, if a validating party 52 needs access to a passport 63, a driver's license, and a college diploma 64, user 51 must assign a sufficiently low weighting to each such member (or connection between members) so that each of those three members can be accessed by validating party 52.

[0042] In a Web of Trust implementation, trust relationships are established between users who wish to communicate with each other. Each user decides which of the other users they should trust and to what extent. The user signs the public encryption key of each other user they trust and also assigns a trust value (e.g., a number in the range of 1 to 255) indicating the degree of trust. Calculations are performed by adding the trust values. Similarly, in FIG. 6 , each member of identity resource set 60 can sign an identity key (public encryption key), and a trust value is assigned to that member of identity resource set 60 by validation party 52, thereby enabling the calculation of points for a particular grouping of one or more members of identity resource set 60. For example, bank 52 can specify that it trusts driver's licenses with 30 points and passports with 40 points, and bank 52 can specify a policy that user 51 should be considered trusted if the total point value exceeds a certain threshold.

[0043] Thus, embodiments of the present disclosure provide a new security and trust solution for user verification relative to conventional technologies. With traditional PKI approaches, a centralized (trusted) certificate authority is relied upon to issue and sign digital certificates. The CA binds public encryption keys to the respective identities of the entities that own (or at least control) those keys. However, reliance on a trusted CA (whether it be a hierarchy of CAs or a single entity) inherently involves a single point of failure. However, in contrast to traditional PKI technologies, one or more embodiments of the present disclosure do not require users to rely on a centralized CA to prove their identity to a validation entity.

[0044] In an alternative approach to PKI, the traditional decentralized Web of Trust (WoT) model attempts to resolve this centralized dependency. Instead, in WoT, levels of trust are determined and assigned to specific entities through the binding / association of keys to that entity by other users in the Web. As explained at https: / / en.wikipedia.org / wiki / Web_of_trust, "OpenPGP-compliant implementations also include a voting tallying scheme that can be used to determine which public key-owner associations a user should trust while using PGP. For example, the association between the owner and public key in a certificate is trusted as correct if three partially trusted endorsers have vouched for the certificate (and thus the public key-owner binding contained therein), or if one fully trusted endorser has done so. The parameters are user-tunable (e.g., no parts, or perhaps six parts) and can be bypassed entirely if desired."

[0045] Thus, in prior art WoT approaches, a key is associated with the entity that owns / controls it. In contrast, embodiments of the present disclosure can enable the construction of a Web of Trust in which a validation entity assigns levels of trust (e.g., point values) to different specific identity resources, rather than simply to the information source. Embodiments can be used to extend traditional WoT so that validation entities in the Web can apply not only their own parameters to determine the trustworthiness of an information source, but also the type, nature, and importance of identity-related resources, e.g., documents, issued by other users. Thus, embodiments can provide a different technical solution compared to traditional trust models used for identity verification, e.g., WoT or PKI.

[0046] The flowchart in Figure 7 shows the steps to be performed by logic possibly implemented in storage device 53, such as implemented in the business logic of a smart contract running on blockchain 106.

[0047] In FIG. 7, at step 71, user 51 (FIG. 5) selects a set 60 (FIG. 6) of identity resources 61-65 (FIG. 6) to store in storage device 53. At step 72, this set is stored in storage device 53. At step 73, user 51 shares access credentials with a validation party (or multiple validation parties). At step 74, the validation party implements a policy, or set of rules (e.g., by executing logic / code that evaluates the weighting of members of the set of identity resources 60 and / or the connections between such members), thereby selecting one or more members of the set of identity resources. At step 75, the validation party accesses the selected members of the set of identity resources from storage device 53. After validation party 52 has accessed the selected members of the set of identity resources from storage device 53, validation party 52 then reviews them, either manually or by computer automation, to determine whether the validation party is satisfied that user 51 is who they claim to be.

[0048] As an example, consider the banking environment mentioned above. User 51 wishes to open a bank account with bank 52. User 51 selects a set of identity resources including a utility bill 61, a driver's license 62, a passport 63, a university diploma 64, and a bank statement 65, and stores this selected set of identity resources in storage device 53 (steps 71 and 72 of FIG. 7 ). This may be done, for example, by storing the data on a blockchain, as described above.

[0049] User 51 then shares the access credentials with bank 52 (step 73). Bank 52 then applies a policy, or set of rules (step 74), for example, by evaluating the weightings of the members of set 60 (or the weightings of the connections between members of set 60) to select members of the set for review. For example, the bank may have a high weighting (of 85) for passport 63 and a high weighting of 90 for bank statement 65, thus indicating to the encoding logic (e.g., smart contract) that these two members of set 60 should be reviewed by bank 52. Bank 52 then accesses the selected members of the set (passport 63 and bank statement 65) from storage device 53 and reviews them to determine whether bank 52 is satisfied that user 51 is who they claim to be.

[0050] Exemplary System Overview A blockchain refers to a form of distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and made publicly available. A blockchain consists of a chain of blocks of data, each containing one or more transactions. Each transaction points to a previous transaction in the sequence, which may span one or more blocks and trace back to one or more coinbase transactions, except for so-called "coinbase transactions," which are described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are created through a process often referred to as "mining," in which multiple nodes compete to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and block publication may be achieved simply through the publication of block headers.

[0051] Transactions in a blockchain may be used for one or more of the following purposes: to transfer digital assets (i.e., multiple digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to time-order index pointers. Blockchains may also be utilized to layer additional functionality on top of them. For example, blockchain protocols may allow additional user data or indexes to data to be stored within a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and thus increasingly complex data may be incorporated. For example, this may be used to store electronic documents or audio or video data on a blockchain.

[0052] In an “output-based” model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output includes an element specifying the amount of a digital asset derivable from an ongoing sequence of transactions. A spendable output is sometimes referred to as a UTXO (or “unspent transaction output”). An output may further include a locking script that specifies the conditions for the output’s future redemption. A locking script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coin-based transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Consider a pair of transactions, called a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output specifying the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0053] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the validity criteria applied by each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another is that the output of the first transaction has not already been redeemed by another, previous, valid transaction. A node that finds the target transaction invalid according to any of these conditions neither propagates it (as a valid transaction, but possibly to register an invalid transaction) nor includes it in a new block to be recorded on the blockchain.

[0054] An alternative type of transaction model is the account-based model, where each transaction defines the amount transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing absolute account balances. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain.

[0055] 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 (often referred to as "miners") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not illustrated, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0056] Each blockchain node 104 includes a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including 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), and other devices such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage devices in the form of non-transitory computer-readable media. The memory may include one or more memory units employing 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.

[0057] A blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 within a decentralized or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain includes one or more transactions 152, with a transaction in this context referring 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 uses one particular transaction protocol throughout.

[0058] A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Blockchain nodes 104 may be configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Blockchain nodes 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as valid, for which the node 104 is obligated to not accept any other transactions attempting to consume the same output.

[0059] For a given current transaction 152j, the (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 "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although that is certainly one common use. More generally, consuming may be described as consuming an output or allocating it to one or more outputs in another, further transaction. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to a preceding element in a logical sequence linked by a pointer, not necessarily at the time of creation or transmission in the temporal sequence, and thus does not necessarily preclude a transaction 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i can equally be referred to as a previous transaction or a preceding transaction.

[0060] Due to the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server including one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 could also take the form of a user terminal or a group of networked user terminals.

[0061] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0062] Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, a node may specialize in a particular operation. For example, a node 104 may focus on transaction validation and propagation or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Reference to a blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0063] Also connected to the network 101 are computer devices 102 for each of a number of parties 103 who act as consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., obtaining copies of the blockchain from blockchain nodes 104).

[0064] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the necessary roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 by connecting to (i.e., communicating with) a blockchain node 106, thereby utilizing the blockchain 150. 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 100, but are not illustrated for convenience. 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, although it will be understood that this is not intended to be limiting and that references herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0065] 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 further includes memory, i.e., computer-readable storage devices in the form of non-transitory computer-readable media. This memory may include one or more memory units employing 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 include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0066] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on a suitable computer-readable storage medium, for example downloaded from a server, or may be 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, an optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

[0067] The client application 105 has at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150. The other is to report to each party the amount of digital assets they currently own. In an output-based system, this second functionality involves reconciling the amounts belonging to the party of interest as determined in the outputs of various transactions 152 scattered throughout the blockchain 150.

[0068] NOTE: While various client functionalities may be described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may instead be implemented as a set of two or more different applications, for example, interfacing via an API or plugging one into the other. More generally, client functionality may also be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following description will be given with respect to client application 105, it will be understood that this is not limiting.

[0069] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the 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 the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or indeed to inspect the transactions of other parties in the blockchain 150, since in embodiments 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. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to one another; a given transaction protocol goes with a given node protocol and together implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0070] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the transfer amount not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing an absolute account balance. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called a "position" or "nonce"). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field may refer to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0071] Some account-based transaction models share some similarities with the output-based transaction model described herein. For example, as noted above, the data field of an account-based transaction points to a previous transaction, which is equivalent to the input of an output-based transaction, which references the outgoing point of the previous transaction. Thus, both models enable links to be established between transactions. As another example, an account-based transaction includes a "recipient" field (where the receiving address of the account is specified) and a "value" field (where the amount of a digital asset may be specified). The recipient and value fields together represent the output of an output-based transaction, which can be used to assign the amount of a digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field, which contains a signature for the transaction. The signature is generated using the sender's private key and verifies that the sender authorized the transaction. This typically corresponds to the input / unlock script of an output-based transaction, which includes the signature for the transaction. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and can be recorded on the blockchain. In an account-based blockchain, a "smart contract" refers to a transaction that includes a script configured to perform one or more actions (e.g., sending or "releasing" digital assets to a recipient address) in response to one or more inputs (provided by the transaction) satisfying one or more conditions defined by the smart contract's script. Smart contracts exist as transactions on the blockchain and can be invoked (or triggered) by subsequent transactions.Thus, in some examples, a smart contract may be considered equivalent to a locking script for an output-based transaction that may be triggered by a subsequent transaction and checks whether one or more conditions defined by the locking script are met by the inputs of the subsequent transaction.

[0072] 3. UTXO-based Model Figure 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but may equally be implemented on other exemplary blockchain networks.

[0073] In a UTXO-based model, each transaction (“Tx”) 152 comprises 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) that can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies the amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also comprise a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, 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 node 104.

[0074] For example, Alice 103a wants to create transaction 152j to transfer an amount of digital assets of interest 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 mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could also refer to any previous (i.e., previous) transaction that still has unspent outputs 203 locked for Alice.

[0075] The terms “predecessor” and “successor,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence as defined by the transaction pointers specified in the transactions (e.g., which transactions point to which other transactions). These could equally be interchanged with “predecessor” and “successor,” or “predecessor” and “descendant,” “parent” and “child,” or the like. This does not necessarily imply the order in which they are created, transmitted to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or “child”) that points to a preceding transaction (previous transaction or “parent”) is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to await its parent, depending on the node protocol and / or node behavior.

[0076] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO 0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script of the subsequent transaction's input 202 for the subsequent transaction to be validated and therefore the UTXO to be successfully redeemed.

[0077] A locking script (aka scriptPubKey) is a fragment 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), used in blockchain networks. A locking script specifies the information needed to consume a transaction output 203, for example, Alice's signature requirements. A locking script appears within the transaction's output. An unlocking script (aka scriptSig) is a fragment of code written in a domain-specific language that provides the information needed to satisfy the locking script's criteria. For example, this could include Bob's signature. An unlocking script appears within the transaction's input 202.

[0078] Thus, in the illustrated example, UTXO0 in Tx0's output 203 must contain 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 Locking script [Checksig P A ] is equipped. [Checksig P A ] is Alice's public key P from her public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer to Tx1 (e.g., using 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 distinguish it from any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that contains Alice's cryptographic signature, created by Alice applying the private key from her key pair to a predefined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0079] When new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol, which involves running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria).

[0080] Note that script code is often expressed generally (i.e., without using a precise language). For example, operation codes (opcodes) may be used to express specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a locking script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored on the blockchain.

[0081] Typically, the input to a transaction is a public key P A In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the outputs it signs depend on the SIGHASH flag, which is a four-byte code typically included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

[0082] A locking script is sometimes referred to as a "scriptPubKey," referring to the fact that it typically includes the public key of the party to whom each transaction is locked. An unlocking script is sometimes referred to as a "scriptSig," referring to the fact that it typically provides the corresponding signature. However, more generally, in all applications of blockchain 150, it is not essential that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language can be used to define any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0083] 4. Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 102b may each include additional communication functionality. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of some party or a third party). The side channel 107 allows for the exchange of data away from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively, or in addition, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0084] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively, or in addition, 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 102a and Bob's device 102b. In general, a side channel 107 referenced anywhere herein may include any one or more links over one or more network technologies or communication media for exchanging data “off-chain,” i.e., separate from the blockchain network 106. When multiple links are used, the bundle or collection of off-chain links may be referred to as the side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange some information or data or the like over the side channel 107, this does not necessarily imply that all pieces of this data must be transmitted over the exact same link or the same type of network.

[0085] 5. Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the presently disclosed scheme. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as to formulate transactions 152, receive and / or send transactions and / or other data via side channels 301, and / or send transactions to one or more nodes 104 for propagation through the blockchain network 106, in accordance with the scheme described above and as will be described in more detail shortly.

[0086] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of each user's computing device 102, including outputting information to each user 103 via the device's 102's user output means and receiving input back from each user 103 via the device's 102's user input means. For example, the user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing audio output, and / or one or more tactile output devices for providing tactile output, etc. The user input means may also include, for example, an input array of one or more touchscreens (the same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or audio input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or one or more mechanical buttons, switches, joysticks, etc.

[0087] Note: While various functionalities described herein may be described as being integrated into the same client application 105, this is not necessarily limiting; instead, they may be implemented in a set of two or more different applications, for example, one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split across multiple applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made elsewhere in this specification to a single or given application 105, or the like, it will be understood that this is merely an example, and that, more generally, the described functionality may be implemented in any form of software.

[0088] 3B shows a mockup of an example user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by client 105b on Bob's device 102b, or on another party's device.

[0089] 3B shows a UI 500 from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 502 that are rendered as different UI elements via user output means.

[0090] For example, the UI elements may include one or more user-selectable elements 501, which may be different on-screen buttons, or different options in a menu, or the like. User input means are arranged and configured to allow user 103 (in this case, Alice 103a) to select or otherwise manipulate one of those options, such as by clicking or touching the UI element on the screen or by speaking the name of the desired option (Note: as used herein, the term "manual" is meant only in contrast to automatic and is not necessarily limited to the use of hands or both hands).

[0091] Alternatively, or in addition, the UI elements may include one or more data entry fields 502. These data entry fields may be rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touch screen. Alternatively, data may be received verbally, e.g., based on voice recognition.

[0092] Alternatively or additionally, the UI elements may include one or more information elements 503 that are output to output information to the user. For example, this / these may be rendered on a screen or audibly. It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data is not important. The functionality of these UI elements will be described in more detail shortly. It will also be understood that the UI 500 shown in FIG. 3 is merely a schematic mockup and may, in fact, include one or more additional UI elements that are not illustrated for the sake of brevity.

[0093] 6. Node Software FIG. 4 illustrates an example of node software 450 executed on each blockchain node 104 of the network 106, using an example UTXO or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the required actions of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including one or more of a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). The consensus module 455C may include a validation module (not shown) configured to validate transactions according to the blockchain protocol. The validation module may instead be separate from the consensus module 455C. One or more of the modules may operate in parallel. The node 104 may include additional modules. The protocol engine 401 is typically configured to recognize different fields of the transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) output (e.g., UTXO) j ) is received, the protocol engine 451 j The protocol engine 451 identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and extract Tx i may be published on the blockchain 150, in which case the protocol engine derives Tx from a copy of block 151 of the blockchain 150 stored on the node 104.i Alternatively, Tx i may not yet be published on the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 may extract Tx i The script engine 452 then identifies the locking script in the referenced output of the script.

[0094] Therefore, the script engine 452 executes the Tx i Locking scripts and Tx j , and the corresponding inputs of the transaction. For example, transactions labeled Tx0 and Tx1 are illustrated in FIG. 2, but the same could apply to any pair of transactions. Script engine 452 executes the two scripts together as previously described, which includes placing data on and popping data from stack 453 according to the stack-based scripting language being used (e.g., Script).

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

[0096] In an output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are also one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, e.g., Tx j The total value of the digital asset specified in the output of Tx does not exceed the total value indicated by its input. i The pointed-to output of has not already been consumed by another valid transaction, etc. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions and executes transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. Tx j is actually valid, the decision engine 454 controls both the consensus module 455C and the propagation module 455P to j This is because the consensus module 455C may choose to perform the respective blockchain-related functions with respect to Tx j to each ordered set of transactions 154 of the node, and the propagation module 455P j to another blockchain node 104 in the network 106. Optionally, in embodiments, the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to only publish a transaction conditional on the transaction being valid and having sufficient remaining transaction fees.

[0097] Also, note 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 this 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, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of the signature and an additional positive output of the smart contract (with the overall result considered to indicate true if both individual outcomes are true).

[0098] 7. Further Notes Other modifications or use cases of the disclosed technology will become apparent to those skilled in the art after reading the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0099] For example, some embodiments above have been described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is a particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 described above.

[0100] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, network entities may perform the functions of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered nodes of the preferred Bitcoin network 106).

[0101] In other embodiments of the present invention, blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, in these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but does not store and / or propagate those blocks 151 to other nodes.

[0102] More generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware using the same methods as described above with reference to blockchain node 104.

[0103] Some embodiments have been described in terms of a blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is merely one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-age. As a specific example, proof-of-stake uses a randomized process to determine which blockchain nodes 104 will be given the opportunity to generate the next block 151. The selected nodes are often referred to as validators. Blockchain nodes can lock tokens for a certain period of time to have the opportunity to become validators. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0104] Enumerated Statements It will be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements: Any feature presented below with respect to one set of statements is not limited as such and may be incorporated into one or more other sets of statements.

[0105] According to one form of expression, embodiments of the present disclosure may provide a method and / or system for validating a user's identity, establishing a user's identity, and controlling access to controlled resources, such as services and / or physical / electronic resources. Additionally or alternatively, embodiments of the present disclosure may be described as providing a security method / system / apparatus, preferably for protecting access to controlled resources, such as services or physical / electronic resources. Additionally or alternatively, embodiments may be described as facilitating an improved Web of Trust (WoT) solution (method, system, or apparatus).

[0106] In an additional or alternative form of expression, the present disclosure may provide a computer-implemented verification method for verifying a user's identity, the method comprising: selecting, or attempting to select, by the validation entity at least one identity resource from a set of identity resources made available to the validation entity by the user for verifying the user's identity, The selection or attempted selection of at least one identity resource from the set of identity resources includes a step performed according to at least one rule or selection criterion established by the validation entity.

[0107] In some or more embodiments, one or more identity resources in the set of identity resources may be assigned a respective weighting by a validation entity and / or according to at least one rule or selection criterion. In other words, the identity resource, or each of the identity resources among the plurality of identity resources, may be assigned a weighting or value, which may be assigned by the validation entity.

[0108] Additionally or alternatively, a connection, association, or combination between at least two of the identity resources in the set of identity resources may be assigned a weighting.

[0109] The weightings may be used by a validation entity to establish a user's identity, which may involve (including) evaluating the weightings or combined weightings against a threshold predetermined by the validation entity. If the weightings or combined weightings of the user's identity resources meet or exceed the threshold, the user's identity may be considered validated, or not validated if the threshold condition is not met.

[0110] Statement Set 1 According to one possible expression, an embodiment of the present disclosure may provide the following:

[0111] 1. A computer-implemented method comprising: A computer-implemented method comprising: attempting, by a validation entity, to select at least one identity resource from a set of identity resources made available to the validation entity by a user to verify the user's identity.

[0112] The attempt to select at least one identity resource from the set of identity resources may preferably be performed according to at least one (software automated / enforced) rule or selection criterion established by a validation entity.

[0113] The validation entity may be the owner, controller, and / or provider of the controlled resource. Successful verification of a user's identity may be required by the validation entity before allowing the user access to the controlled resource. The validation entity may generate or use at least one rule, policy, and / or criterion for establishing successful verification of the user's identity. The at least one rule, policy, and / or criterion may specify which, how many, and / or what type of identity resources are required for successful identity verification of a (certain person or user), or any other criteria related to identity resources that the validation entity determines to be relevant for verification purposes. Additionally or alternatively, the at least one rule, policy, and / or criterion may specify which identity resources can be combined to satisfy the validation entity's requirements for successful identity verification. To facilitate this, different types, formats, or other parameters related to identity resources may be assigned respective weights or values ​​or "points." At least one rule, policy, and / or criterion may specify a threshold or number of points that must be reached by selecting one or a combination of identity resources from the set of identity resources for identity validation to be successful. At least one rule, policy, and / or criterion may specify a minimum or maximum number of identity resources that can be combined to reach the threshold. If the validation entity is unable to select the number, type, or other form of identity resources from the set of identity resources necessary to reach the threshold, the attempt to verify the user's identity may be rejected and considered a failure.

[0114] The set of identity resources may be selected and / or generated by a user. The set of identity resources may be made available to a validation entity by a user by providing the set of identity resources in or on a storage device. The storage device may be a blockchain. The set of identity resources may be managed by a digital wallet. When we say that an action is performed "by a user," this may mean that the user themselves performs the action, for example, through an interface to a software component or system, or that the action is performed automatically by a software system / component owned / controlled / operated by the user, and the action is performed on the user's behalf via the system / component.

[0115] The users and / or validation entities may be actors or participants in a Web of Trust and / or Public Key Infrastructure (PKI) deployment / implementation / system.

[0116] A set of identity resources may be made available to a validation entity by a user by sharing access credentials by the user to the validation entity.

[0117] The access credentials are i) may include one or more of a password, PIN, passcode or other identifier, or encryption key; and / or ii) may be generated by a user; and / or iii) can be associated with or assigned to a validation entity by a user;

[0118] The set of identity resources may be made available to the validation entity by a user using the blockchain. The set of identity resources may be included in or referenced from transactions on the blockchain. At least one rule or selection criterion may be implemented in a smart contract configured to run on and / or interact with the blockchain.

[0119] At least one rule or selection criterion may be implemented in software logic.

[0120] In some embodiments, one or more identity resources in the set of identity resources may be assigned a respective weighting. The weighting may alternatively be referred to as a value or a number of points. The weighting for a given identity resource may be determined by a validation entity. Additionally or alternatively, it may be determined according to at least one rule or selection criterion and / or implemented as part of software logic for the at least one rule or selection criterion. A connection, association, or combination between at least two identity resources in the set of identity resources may be assigned a weighting, value, or number of “points.” The weighting may be used to determine that at least one identity resource in the set of identity resources should be selected according to the at least one rule or selection criterion.

[0121] Verification of the user's identity may be rejected by the validation entity if no identity resource can be selected from the set of identity resources according to at least one rule or selection criterion. The method may include attempting to verify the user's identity using at least one identity resource selected from the set of identity resources.

[0122] At least one of the identity resources in the set of identity resources may be signed, encoded, protected, or otherwise associated with a cryptographic key. The cryptographic key may be owned, controlled, or associated with an issuing entity of at least one identity resource. The cryptographic key may be part of a key pair. It may be a private key. A validation entity may use the corresponding cryptographic key (e.g., a public key corresponding to a private cryptographic key) to validate / check that at least one identity resource was validly issued by an (authorized, legitimate) issuing entity. The issuing entity, validation entity, and / or user may be actors or participants in a Web of Trust or PKI.

[0123] The method may include denying access to the controlled resource if verification of the user's identity is rejected, or allowing access to the controlled resource if verification of the user's identity is successful.

[0124] The set of identity resources may be selected and / or generated by a user as a subset of a larger set of identity resources. This may be performed according to at least one (automated) rule, policy, or standard applied by the user or by a software component controlled / owned / operated by the user. For example, a user may determine that documents containing the user's social security number may only be provided to a validation entity that is a government agency, or that a degree certificate may only be made available to academic institutions or potential employers for identity validation purposes. Additionally or alternatively, the user may specify on an ad hoc basis which particular validation entities may have access to one, some, or all of the user's set of identity resources. This selection of the set of identity resources may be specified by the user themselves via an interface to the user's software component, e.g., a digital wallet.

[0125] The method may include removing, by a user, at least one identity resource from the set of identity resources. The user may remove one or more resources from the set based on various criteria, e.g., date, privacy concerns, etc. Thus, the user may revoke an identity resource.

[0126] A computer device may also be provided, the computer device comprising: a memory including one or more memory units; The present invention may comprise a processing device including one or more processing units, wherein the memory stores code configured to execute on the processing device, the code being configured to perform the method of any embodiment claimed or disclosed herein when on the processing device.

[0127] A computer program may also be provided, which is embodied on a computer-readable storage and is configured to, when executed on one or more processors, perform the method of any embodiment claimed or disclosed herein.

[0128] Statement Set 2 Alternatively expressed, A computer-implemented method may be provided that includes receiving, from a user, a set of identity resources for proving or establishing the user's identity to a validation entity.

[0129] The terms "prove" and / or "verify" may be used in place of "establish."

[0130] A set of identity resources may include one or more identity resources. Thus, in some embodiments, a set of identity resources may include multiple identity resources, while in other embodiments, a set of identity resources may include only one identity resource.

[0131] The method may include providing one or more of the set of identity resources in a storage device. Instead of "providing," the terms "registering," "uploading," and / or "storing" may also be used.

[0132] The method may include identifying and / or selecting at least one identity resource from the set of identity resources according to selection criteria established by the validation entity. Instead of "established," the terms "determined," "selected," and / or "designated" may also be used.

[0133] The method may include providing the validation entity with access to at least one selected identity resource of the set of identity resources by sharing access credentials with the validation entity.

[0134] The storage device may include a blockchain. The set of identity resources provided in the storage device may be managed by a software resource, such as a digital wallet. The access credentials may be specific to the validation entity. In other words, the access credentials may be associated (by the user) only with the validation entity.

[0135] The method may include one or more steps in which a set of rules or policies is received from a validation entity. The set of rules may be configured to permit or enable selection of one or more of the identity resources in the set of identity resources. In embodiments in which the storage device is a blockchain, the set of rules or policies may be implemented in or executed using a smart contract configured to run on or in association with the blockchain.

[0136] The set of rules or policies may be implemented in software logic, and preferably each connection between two of the identity resources in the set of identity resources is assigned a weighting, and such weighting is used to determine which of the identity resources in the set of identity resources to select.

[0137] The set of rules or policies may be implemented in software logic, where each of the identity resources in the set of identity resources is assigned a weighting, and such weighting is used to determine which of the identity resources in the set of identity resources to select.

[0138] Statement Set 3 In additional or alternative terms: 1. A computer-implemented method comprising: generating and / or selecting a set of identity resources; and / or Providing one, some, or all of the set of identity resources on or in a storage device. A computer-implemented method may be provided, comprising:

[0139] In some embodiments, the storage device may be a blockchain.

[0140] The method may further include providing the validation entity with access to at least a portion of the set of identity resources.

[0141] The set of identity resources can be created or selected by a user.

[0142] The method may further include determining at least one rule or criterion for validating / verifying the user's identity. The at least one rule or criterion may relate to or be applied (by a validation entity) to one or more identity resources provided by the user. The method may include selecting or attempting to select one or more identity resources from the set of identity resources provided by the user according to the at least one rule or criterion. At least one of the identity resources may be registered on a blockchain or other storage device. At least one of the identity resources may be provided in or referenced from / by a transaction on the blockchain.

[0143] Statement Set 4 Alternatively expressed, A computer-implemented method may be provided that includes providing or using a Web of Trust.

[0144] The user and / or validation entity as described above may be a user or participant in the Web of Trust. The method may further include one or more features described with respect to any one or more of Statement Sets 1 through 3.

[0145] This method is i) attempting, by the validation entity, to select at least one identity resource from a set of identity resources made available to the validation entity by the user to verify the identity of the user; and / or ii) receiving from the user a set of identity resources to prove or establish the user's identity to a validation entity; and / or Generate and / or select a set of identity resources, and / or providing one, some, or all of a set of identity resources on or within a storage device; Preferably, the storage device may be a blockchain; and / or iii) providing the validation entity with access to at least a portion of the set of identity resources; Preferably, the set of identity resources can be generated or selected by a user; and / or iv) determining at least one rule or criterion for validating / verifying the identity of the user; Preferably, at least one rule or criterion relates to or can be applied (by a validation entity) to one or more identity resources provided by the user; and / or v) selecting or attempting to select one or more identity resources from the set of identity resources provided by the user according to at least one rule or criterion.

[0146] One or more of statements sets 1 through 4: i) signing, encoding, or protecting a given identity resource or a certificate related to the identity resource using a (private) cryptographic key, which may be performed by or on behalf of the issuing entity that issued, generated, and / or provided the identity resource. The cryptographic key may be a private key with a corresponding public key, and the public-private key pair may be associated with, owned by, and / or controlled by or on behalf of the issuing entity; ii) using the (public) cryptographic key to check the signature used to sign the given identity resource, to decode the encoded identity resource, and / or to otherwise verify that the corresponding (private) key has been used to sign, encode, or otherwise protect the identity resource; may include:

[0147] The public key may be obtained from an issuing entity associated with the identity resource and / or from the Web of Trust.

[0148] According to another aspect disclosed herein, there may be provided a computer program embodied on a computer-readable storage and configured to, when executed on one or more processors, perform the method of any of the embodiments disclosed and / or claimed herein.

[0149] According to another aspect disclosed herein, a system may be provided, the system comprising a computing device having a memory including one or more memory units and a processing device including one or more processing units, the memory storing code arranged to execute on the processing device, the code configured, when on the processing device, to perform a method of any embodiment disclosed and / or claimed herein. [Explanation of symbols]

[0150] 51 users 52 Bank 53 Storage Devices 60 Identity Resources 61 Utility Bill 62 Driver's License 63 Passport 64 College Diploma 65 Bank Statements 100 systems 101 Packet Switched Network 102 Computer Equipment 102a Computer Equipment 102a, 102b Computer equipment 102b Computer Equipment 103a First Party 103b Second Party 103 Parties 103a Payer 103a Alice 103b Recipient 103b Bob 104 nodes 105 Client Applications 105a Client Applications 105b Client 106 Blockchain Peer-to-Peer Network 107 Side Channel 150 Blockchain 151 Blocks of Data 152i Preceding Transaction 152i, 152j Transactions 152 blocks 152 transactions 154 Mempool 154 Ordered Sets (or "Pools") 201 Header 202 Input 203 Output 401 Protocol Engine 402 UI layer 450 Node Software 451 Protocol Engine 452 Script Engine 453 stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Storage Module 500 UI 501 User Selectable Elements 502 Data Entry Fields 503 Information Elements 612 connections 613 Connection 614 connections 615 connections 634 connections 635 connections 645 connections

Claims

1. 1. A computer-implemented verification method for verifying the identity of a user, comprising: selecting or attempting to select, by a validation entity, at least one identity resource from a set of identity resources made available to the validation entity by the user for verifying the identity of the user; Including, said selection or attempted selection of at least one identity resource from said set of identity resources is performed according to at least one rule or selection criterion established by said validation entity; i) one or more identity resources in the set of identity resources are assigned a respective weighting by the validation entity and / or according to the at least one rule or selection criterion; and / or ii) a connection, association, or combination between at least two of the identity resources in the set of identity resources is assigned a weighting; method.

2. The method of claim 1 , wherein the set of identity resources is made available to the validation entity by the user by providing the set of identity resources in or on a storage device.

3. i) the storage device is a blockchain; and / or ii) the set of identity resources is managed by a digital wallet; and / or 3) The method of claim 1 or 2, wherein the user and / or validation entity is an actor or participant in a Web of Trust or a Public Key Infrastructure.

4. the set of identity resources is made available to the validation entity by the user by sharing access credentials by the user to the validation entity; Preferably said access credentials include: i) includes one or more of the following: a password, PIN, passcode or other identifier, or encryption key; and / or ii) generated by said user; and / or iii) associated with or assigned to the validation entity by the user.

5. i) the set of identity resources is made available to the validation entity by the user using a blockchain, preferably the set of identity resources is included in or referenced from a transaction on the blockchain; and / or ii) The method of any one of claims 1 to 4, wherein the at least one rule or selection criterion is implemented in a smart contract configured to run on and / or interact with a blockchain.

6. i) at least one of the identity resources in the set of identity resources is signed, encoded, protected, or otherwise associated with a cryptographic key owned, controlled, or associated with an issuing entity of the at least one identity resource; 6. The method of claim 1, wherein the validation entity performs a step of validating that the at least one identity resource has been validly issued by the issuing entity using a corresponding cryptographic key.

7. 7. The method of claim 1, wherein the at least one rule or selection criterion is implemented in software logic, and preferably the weighting is used to determine the at least one identity resource in the set of identity resources that should be selected according to the at least one rule or selection criterion.

8. 8. The method of claim 1, wherein the verification of the user's identity is rejected by the validation entity if no identity resource can be selected from the set of identity resources according to the at least one rule or selection criterion.

9. 9. The method of claim 1, comprising attempting to verify the identity of the user using the at least one identity resource selected from the set of identity resources.

10. denying access to the controlled resource if verification of the user's identity is rejected; or granting access to the controlled resource upon successful verification of the user's identity; 10. The method of claim 9, comprising:

11. The method of claim 1 , wherein the set of identity resources is selected and / or generated by the user.

12. The method of claim 1 , wherein the set of identity resources is selected and / or generated by the user as a subset of a larger set of identity resources.

13. The method of claim 1 , comprising removing, by the user, at least one identity resource from the set of identity resources.

14. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units, the memory storing code configured to run on the processing device, the code configured to run the method of any one of claims 1 to 13 when present on the processing device; A computer device comprising:

15. 14. A computer program embodied on a computer readable storage and configured to, when executed on one or more processors, perform the method of any one of claims 1 to 13.

Images