documentation: why don't we simply trust tokenscript by URI

[SmartLayer]

I answered in an email but wonder if others who read the documents want to see something like this before continuing to read how things works.

tokenURI wouldn't be our choice of mechanism to achieve that because
it brings down the level from blockchain to the web (i.e. security-wise,
the file is as reliable as how easy it is to hack the website that serves
the URI; reliability-wise, a website might be under maintenance when
the smart contract is still serving)

Ideally, smart contracts return a or its digest so that
it is irrelevant how the TokenScript file is delivered to the user, as
long as it passes the integrity check. By our design, a TokenScript
file for a new token A is served at the same website where the user
conducts a transaction to obtain A token for the first time.
Alternatively, they can be fetched from IPFS. (Currently, we serve
them collectively in a github repo but will move there when the file
format stabilises a bit more)

Writing a smart contract is a tough job and we didn't want to load the
contract developers with the additional task of maintaining
TokenScript trust relationship in the smart contract while they
struggle to minimise the attack surface. For that reason, we designed
Express-Of-Trust transactions. Such a transaction is a simple
(non-smart-contract) transaction sent from the contract's deployment
key to a recipient address calculated from the TokenScript and the
contract. (revocation is done in a similar fashion). The detail in the
docs. This allows smart contract authors to deploy the contract
first, and write TokenScript later and entrust it without having to
update the contract.

Eventually, some smart contract will want to express trust to
TokenScript through explicit functions, as the management grows beyond
the "single-admin-key-does-everything" paradigm. For example, the
deployment key might be safeguarded for upgrading smart contracts
only, and a separate key is designated for updating of the TokenScript
it trusts, allowing them to be taken care by two different departments
or released at different intervals (e.g. release a TokenScript to
ready users for a smart contract migration; then update the smart
contract). When things get to that level of complexity, we will
introduce a spec for smart contracts to return a or its
digest

Might @jzaki help to sort out the doc https://github.com/AlphaWallet/TokenScript/blob/master/doc/authenticity%2Btrustworthiness.md so that it makes sense to readers?