I wanted to give my feedback on the Tokenscript design paper from a security stand point.
It seems to me the main security issue is forming a chain of trust, all the way throughout the process across Ethereum and the web. In particular, when using a web interface to interact with a token in some way, the user must be able to trust the webpage (and thus what it shows). Normally this is achieved through the TLS certificate the website holds. However, that does not say anything about the website’s authenticity on the blockchain. I would image that this can be ensured using a link in the dApp associated to the specific website, or even better, a link to the public key fingerprint of the website’s TLS certificate. But a thing that further complicates this is that the token provider's TLS key gets refreshed at regular intervals, unlike their Ethereum key. Thus a chain of the history of trusted TLS keys must also be stored somewhere. (By a chain I mean that before updating the TLS certificate key, the old key is used to sign the new certificate.)
If we specifically consider the scenario where tokens are going to be used to do sign-on, or want to enhance the security, a user could authenticate the site by giving the site a challenge which it must sign using a key associated with its Ethereum assets. It does not have to be the same key as it uses with its Ethereum account, but just one that has been signed with its “master” Ethereum key.
Another issue is trust between the TBML writer and the parties issuing tokens according to this specification. We must ensure that just because a smart contract says it issues a certain type of TBML token, that this token is redeemable and usable with other websites/dApps. For this we might require the TBML writer to sign a list of public keys of trusted token providers' TLS certificates.
In conclusion: It is crucial that a user visiting a website verifies the authenticity of the site by first looking up the dApp/smart contract on the blockchain which the website refers to, and then verify that this dApp contains a link or public key fingerprint which matches the website/TLS certificate the user is visiting. It is essential to go this direction since a signed reference to a dApp on the website does not ensure that the dApp owner is also the website owner.