-
Notifications
You must be signed in to change notification settings - Fork 72
General Nomenclature
This page is about TokenScript concepts, Mobile-wallet-specific stuff goes to Mobile Wallet Nomenclature
If a web service supports multiple tokens, or that it only supports one token, and a user has multiple instances of it, Token Negotiation is the process of finding the match. Token here is a broad word. It also covers the matching of attestations.
A card has one or more <view> or <audible>. One of the <view> can be an iconified view. <audible> is to be implemeneted for accessibility.
An action card either produces a blockchain transaction or an attestation. A token card just renders a token or an attestation.
A token can have as many token cards as its contexts, and limitless action cards. Most action-cards are only used by the token's owners, but a token-card doesn't assume the context being in the user's wallet.
For example, Alice, a car owner, has a Car token with a "lend" action, which is an action-card. Alice uses it to produce an attestation "AuthorisationToUse" to Bob. That AuthorisationToUse would cause the car token to be rendered in Bob's wallet context (Bob can see it in his own wallet), which is a token-card.
A TokenScript can be signed by one or more entities or trusted by one or more entities. By signing, it is associated with an identity. Currently, we relax the requirement to allow web certificate, which is typically not supposed to be used in Signing, to sign a TokenScript, indicating that the TokenScript is authored by a certain website's team. AlphaWallet-issued TokenScripts are signed with a DV certificate with higher authenticity, as a 3rd-party has verified the organisation (AlphaWallet Pty Ltd).
The signing of TokenScript does not indicate the TokenScript has anything to do with the very token for which it is providing essential security functions (e.g. forming a transaction). That part is dealt with Express-of-Trust.
An express-of-trust is a normal Ethereum transaction coming from a token contract's deploying address, showing that the same person who deployed the token contract trusts the TokenScript. The recipient address is one that is calculated from the TokenScript's DigestValue. The amount can be anything, normally zero but any ether sent in that transaction is considered a tip to the TokenScript project. More in the document
Data useful for transactions and attestations. If a data-object is signed, it's called an attestation. A data object is either used as an attestation (therefore signed) or in a transaction (therefore also signed). Work is in progress to use it to replace ABI in DvP transactions for security reasons (more on that later). Since signed-data can't be altered without invalidating the signature, it has to stand the test of time and interoperability challenges. Since it often consumes gas it also needs to be small.
A data object typically starts with an objectClass, for reuse purpose.
Attestations are signed Data Objects. If defined looser, it refers to anything that is signed, since signing is the act of attesting something. If defined stricter, it has two variations: pure attestation, which cannot be transferred, and convertible attestations, which can be converted into a blockchain token and thus is transferrable. Identity attestation belongs to the former category, while Ticket attestation - attesting to one's right to enter a football venue - belongs to the latter.
Traditional (x.509) certificates are a subset of attestations. An attestation can attest to anything, while a certificate attests to a public key. One can have an attestation that contains no public key (nor other forms of it like Ethereum address), but a certificate must contain a public key.
Here is an example of how the two can be used together. Alice wishes to send 3 ethers to Bob, but he doesn't know Bob's Ethereum address. She signs a message authorising whoever can prove that he is Bob to redeem 3 Ether from her wallet (a contract). That is an attestation. Bob acquires a certificate from an authority, binding his identity to an Ethereum address. He can then use the attestation from Alice, plus his own certificate, to redeem the money from Alice's wallet.
The example simply illustrates the concept of attestation and certificate. In reality, such a protocol has to be modified to be used anonymously.
Again smart account is not smart. It simply has richer and rigid functions and security risks that come with them, thanks to being driven by a smart contract.
A smart account might have any of these features:
- Authorisation - user authorises someone to take money from his Smart Contract Wallet.
- Delegation - user chooses some smart contract or someone to trade for him.
- Security Policies - take threshold policy for example. A user configures a threshold so that transactions beyond the threshold require 𝑛 days of delay or 3rd party signature or the use of a hardware wallet.
- Account Recovery - user chooses a few friends or authorities to assign the account ownership to a new key pair.
- Deadman's switch - the money is redeemable by a beneficiary if not touched 3 years.
The concept is about lots of small tokens which are usually used in one single context. Take Diablo (PC Game) for example, its backpack has weapons, armours, runes and diamonds. Some of them might be usable in other games, but a set of them are used in one journey (say, Diablo). Such a set is a backpack.
It probably should be called Token VM instead. We are not fixed on the term. It's the runtime environment of TokenScript when it runs in a web context.
It is called enclave because it is a secure zone not belong to the web page that uses it.
-
The JavaScript on the web can't inspect the memory of the enclave. Instead, it communicates with the enclave through an API available to JavaScript.
-
The JavaScript can't feed information into the enclave. Instead, the enclave takes information from attestations, blockchain nodes and whitelisted data sources.
The use-cases of token enclave will be a page of its own on tokenscript.org. For one example, it's safe to generate a zero-knowledge proof of a token or a token attribute inside the enclave so the proof can be used on the website. If this is done in traditional JavaScript, the website would have had access to the data itself, making zero-knowledge proof a moot point.
The token enclave can potentially run in a hardware security enclave as well. For now, it's a concept not implemented yet.
Again a concept that we have not properly named. A website might offer a TokenScript for the purpose of constructing a transaction securely. The logic for the construction of such transactions might be signed by different vendors in different TokenScripts. It's possible for the website to produce a MishMesh as long as the signature is done in such fine way that sections of TokenScripts are signed, it's possible to produce a MishMesh TokenScript without invalidating any of the signatures. It's useful for DvP transactions.
Security measurements for DvP transactions usually require Merklised payload. It worth an article of its own.