Skip to content

Latest commit

 

History

History
34 lines (21 loc) · 4.32 KB

README.md

File metadata and controls

34 lines (21 loc) · 4.32 KB
Raw

What is TACo?

TACo (Threshold Access Control) is an encrypt/decrypt API for application developers who require:

  • end-to-end encrypted channels for their users to share private data safely
  • programmable, composable access logic and conditionality
  • an alternative to centralized access control and its associated trust burdens
  • 100% open source software, running across a permissionless network, fully decentralized from day one

TACo's production (mainnet) API is already being utilized in the wild – enforcing decryption rights for media libraries, securing the passage of inheritance assets, and enabling safe account recovery. For more examples, check out Use Cases.

Integrating TACo into your web/web3 app, infrastructure or protocol only takes a few steps – see the Quickstart guide.

Overview

Apps that have integrated the TACo SDK automatically interact with the taco-web encrypt/decrypt API. This connects end-users directly to TACo's network of distributed nodes – with no intermediaries.

In a typical flow, private data is encrypted client-side by a data producer. This data payload will remain encrypted until it reaches the device of a qualifying data consumer. From a privacy point of view, this is equivalent to the end-to-end encryption guarantees in a messaging app like Signal. However, TACo is general-purpose and can protect data flows in all types of applications, rather than being optimized for point-to-point textual communication.

Whether or not a data consumer qualifies to decrypt and view a given data payload depends on whether they fulfill certain access conditions. These conditions are specified in advance by the producer or owner of that data, or programmed into the application logic on their behalf. For example, a journalist-facing app might predicate access to submitted evidence based on the proven location of the witness (out of harm's way).

To access the data, a given data consumer will have to (1) authenticate themselves and (2) present proof they fulfill the pre-specified conditions. Both are evaluated by a group of TACo nodes, each of which individually validates the data consumer's request by comparing it to retrieved web/web3 state. For example, if perishable health data should not be shared after a certain date, TACo nodes will simply read the UNIX epoch via Ethereum's block.timestamp value.

If a sufficient number (a 'threshold') of nodes confirm that the requesting data consumer qualifies to see the data, they will send their device some key fragments. These fragments can be put together by the requestor client-side, which produces a decrypting key. This decrypting key can then be used to decrypt the original private data – or more often, a sym key which provides a lightweight conduit to the underlying payload.\

TACo vs. Alternatives

If your app handles any form of private or sensitive data, your choices as a developer (excluding TACo) are fairly limited:

  1. Basic Public Key Infrastructure. Although client-side, asymmetric encryption is privacy-preserving (and free), it requires knowing the identifier of a data consumer in advance and doesn't typically scale beyond a demo or app prototype.
  2. Cloud Key Management Systems. Although straightforward to integrate (and cheap), using a KMS effectively trusts the cloud provider with all of your users' data, given that they ultimately control the master key and can theoretically (and silently) access everything.
  3. Decentralized-In-Name-Only Protocols. Although DINO projects claim they are decentralized (or will eventually decentralize), their 'network' is often a permissioned group of insiders – who all know each other and have no (crypto)economic incentive not to collude. In addition, from a regulatory perspective, a permissioned coterie based in a single jurisdiction presents single-point-of-failure risks.
  4. Trusted Execution Environments. Although TEEs have powerful capabilities, they come with an opaque and unpredictable supply chain risk, with many examples of vulnerabilities and exploits. Moreover, they are costly and challenging to run, and therefore difficult to decentralize and expensive, restrictive overkill for an access control service.