An attestation is a claim cryptographically attested by an attestor's signature. TokenScript enables wallets to create and manage attestations.
What is an attestation?
Attestation are a claim on something: On a national identity, on the legal drinking / voting age, an university degree, the ownership of an email address, an insurance and so on.
Technically, an attestation is a data object (or file) which claims something and is signed by an attestor. In some cases an attestation can be self signed, for example when the claim is to own a certain amount of cryptocurrency (which can be done more privately through attestations).
There are typically three ways to use an attestation:
- As the payload of an attested transactions. The underlying smart contract will check the validity of such attestations. Cheque protocol makes heavy use of attestations in such a way.
- To prove something to a 3rd party. For example, you can construct a proof of your email address with an email address attestation.
- To provide dependency for other attestations. Since Attestation can be chained.
TokenScript supports the integration of attestation processes, triggered by an action card directly in the wallet. You can integrate an attestation circuit into the life cycle of a token.
Attestation use cases
A standardized attestation format has an enormous potential to smoothly integrate identity and other claims into the web and to streamline a wide range of processes, like signing up for an exchange, registering a bank account, verifying as an accredited investor for an Security Token Offer or renting a car.
For example, you could create a smart contract for an ICO which requires that participants provide an attestation to be an accredited investor. With TokenScript a QR code to the smart contract can trigger the attestation process directly in the wallet, and the wallet can use the attestation for any ICO in the future.
Another example would be a car token. When you have the token in your wallet, you can have the option to start an insurance process which will create an insurance attestation connected to the car token. When the wallet has the attestation, TokenScript can unlock the option to take lend the car on a car sharing platform.
There can also be attestations for an activity. For example, a smart contract may allow a blockchain payment to be redeemed on the condition that a specific job is attested as well done. Such a job can be, for example, a car painting job, identified by the job id in the corresponding Smart Contract.
An attestation can also be connected to an Ethereum entity like the holder of a key pair. This allows to create cheques - the transfer of coins from a smart contract to someone who can provide an attestation for an identifier like an email address.
In short: Any delivery vs payment operation can integrate any kind of attestation which might be required for the process.
Attestation versus Blockchain Token
Attestation and blockchain token are related concepts: Both of them require the user to have a private key.
In some use cases attestations and token are interchangeable: For example, a FIFA ticket can be either an attestation or a blockchain token. When it is an attestation, it attests the key-holder's right to enter the venue. When it is a blockchain token, it serves the same purpose, and also might be transferable within the Smart Contract rules.
That reveals the first difference: an attestation isn't transferable, and a token's transferability depends on the smart contract.
The second difference is that attestations are private: They are not stored on the blockchain. Since they often carry private information, they should never hit a blockchain.
The proof of an attestation, however, might be written to the blockchain in an Attested Transaction. This method to process attestations has many advantages over the commonly used approach of third party whitelists.
An attestation is a signed dataObject. The dataObject can contain any information, including public and private information. It can be signed by an Ethereum entity and attested to a token.
Attestations are non-transferable, but transferability can be achieved by attesting to another attestation.
Attestations can be fully expressed by an URI for easy and cross-compatible usage. This allows to create Magic Links which contain an attestation.
The attestation format takes close inspiration from the X.509 certificate specification, RFC-5280, but makes several fields optional, adds a few new ones and changes some formats.
There is still much work to be done. For example, we need a format that can do partial attestation by using Merkle Tree, or even zero-knowledge proof of attestation.
In the Karma Token example a simple demo of an attestation process was implemented. It is declared as an Action Card:
<ts:card type="action" name="attest"> <ts:label> <ts:string xml:lang="en">Attestations</ts:string> <ts:string xml:lang="zh">认证</ts:string> <ts:string xml:lang="es">Attestationes</ts:string> </ts:label> <ts:view xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <style type="text/css">&style;</style> <body>&attestations.en;</body> </ts:view> </ts:card>