I assume a very simple identity token system and try to sketch out the role of TokenScript.
The very simple identity token: Some verification authority checks the passport and give the user an identity token. As long as the token is on a registered address, the user can register at bank accounts and crypto exchanges with a proof of token.
What can TokenScript do? I rather try to understand the concept than to create a design.
TokenScript can use Action Cards in several ways:
let the user sign a message with the address of the token
let the user reverify the identity at the identity provider
let the user depreciate the identity token (in case it his keys were stolen, but he has a backup with the seed)
TokenScript can use Attributes:
to store the hash of the full name or the date of birth or the post address (so exchanges can demand and verify it when the user registers)
Other things I guess TokenScript can do, but I am unsure how it is done:
integrate other services, like insurances, document verification services, social media account (DID -> decentralized identifiers)
There is one thing that puzzles me: If the identity token is a non fungible token (imho it must be) - will there a tokenscript file for each token? Or can dApps download a library-like file which contains all the information?
What do you think? Happy to get some input from you.
Technically we need a few smart contract components too to support such use-case. We submitted EIP 1388, EIP 1386 for those.
Right, with some additional cases that TokenScript can do.
If a website asks for an attestation, an Action Card will pop up to allow the user to prove it.
The simplest attestation being an email address or mobile phone number attestation, so that when you book an airline ticket, the airline website don't have to send you verification emails or verification text-messages (given how many steps are involved in buying an airline ticket they couldn't really do that without worrying cart abandonment). Instead, an attestation shows you own the email address / mobile number.
On the blockchain, such an attestation is useful if you want to send someone a token (say, DAI) but you don't know or wasn't sure of the recipient's Ethereum address. You can send a cheque that is redeemable on presenting the attestation in the redeeming transaction. There are ways to anonymise such a process so the recipient doesn't reveal his email address on the blockchain. We have a protocol designed for this.
Yes.
Identity is best implemented as an attestation. As a non-fungible token, each use of the attestation on the blockchain is linkable, and fields like date of birth shouldn't be on a public blockchain. Besides, there isn't a transfer use-case for identity attestations so you lose a big reason to make it a token.
Regarding "will there be a token script file for each token", you mean "will there be a token script file for each attestation".
Yes, there is a TokenScript for "Email address / mobile number attestation", one for "drinkable age attestation", one for "Citizenship attestation", one for "Hotel serviceability attestation" (if you have a token that represents the right to stay somewhere the hotel might need to attest their capacity to service). You might even have short-lived attestations issued by less prominent "authorities", like one for "authorised to pick up delivery packge on behalf of another" attestation, and one for "authorise to drive someone's car" attestation.
If you have 2 email address attestations, you will only have one TokenScript (that is "Email address attestation" TokenScript) and 2 attestations by that TokenScript. So a TokenScript is a type of attestation, not an instance of an attestation.