A quorum policy is a policy which is used to ensure that different stakeholders approve of some transaction or that a sufficient number of members of a group approve. In either case the goal is to remove the single point of failure which occurs when only one entity is needed to approve a transaction.  

‍

Of course, as is often the case with such policies the devil is in the detail, and many ways of implementing such a policy will introduce a technical single point of failure in the very solution intended to remove the original point of failure. Essentially this is due to a gap in the chain of trust from the approvers to the execution of the approval because security is based on accountability – “after the fact” – rather than authenticity – “before the fact”; the fact being the authorization of the transaction. 

‍

Consider the case of authorizing access to sensitive information in some website e.g. a web bank of a large enterprise. The website itself will grant access based on a digital signature (i.e. using certificates). Implementing a quorum policy can typically be achieved by having an agent (human or machine) controlling the associated private (signing) key, but only using it after receiving the approvals from the constituents of the quorum policy. All these approvals will be recorded after which the agent will use the private key to sign the transaction.  

‍

This introduces a single point of failure as this agent, a person, a machine or code, has full access to the private key and can in principle sign anything at any time. After the fact, it may be held accountable, but by then it may be too late as the person may behave maliciously or the machine or code may become compromised. 

‍

The problem we are facing is that there is a gap between authentication of the transaction (approval) and actually executing it. The final signed transaction is not directly dependent on the approvals provided by the approvers, and this creates a gap in the authorization chain. 

‍

The solution is to have each approver provide their share of an approval signature using a cryptographic algorithm which natively generates the transaction signature only when the required number of approvals is satisfied. This approach eliminates the dependency on any single party to hold the key and execute the signature on their behalf, thus eliminating the single point of failure.  

‍

Threshold Signatures use multiparty computation (MPC) to provide such secure cryptographic services. Models may be specified to require 2 of 3 approvers, 3 of 3, or virtually any m of n combination up to 20 of 20. Each approving party will have a share of a single approval key locally generated on their device. When they provide their approval, MPC verifies that their partial signature has been provided.  

‍

MPC executes across each of the approving parties asynchronously, until MPC confirms that the minimum number of required partial signatures have been validated to fully authorize the transaction. Once confirmed, MPC generates the transaction signature natively, without ever creating a full key, or sharing shares of a key or partial signatures with any parties. The result is secure quorum approvals, without the gap that frequently exists between authentication and execution. 

‍

The decentralized nature of signature approvals using Threshold Signatures are well suited to decentralized applications like blockchain (public and permissioned), but they’re completely independent of blockchain technology and can be applied to any applications require multiple parties to approve digital signing, such as digital transactions, code signing, etc.